Proof Portal
Omarchy
ProbeLabs73 findings · 87 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Exported bash functions execute as root inside apply-lock despite the trusted-PATH replacement
High-severity issue, currently open.
Description
The issue as recorded.
The EUID==0 control (bin/omarchy-apply-lock:15) replaces PATH but leaves the environment intact. Bash imports the exported functions (BASH_FUNC_grep%%, BASH_FUNC_command_not_found_handle%%, ...) into the function table, and function lookup precedes PATH in bash. A caller-supplied grep runs instead of /usr/bin/grep inside the fingerprint gate (line 48). An imported command_not_found_handle returning 0 makes 'if omarchy-shell lock status' (line 62) TRUE with the binary absent (chroot install). Caller-supplied CODE executes with root privileges - the hostile-environment case the PATH pin exists to refuse (SW-REQ-260912-EKJP trusted_path_only) is reachable anyway.
Affected requirements
The requirement(s) this issue violates — click through to the spec.
Severity, explained
Why this is rated the way it is — and the scoring signals behind the rating (each ⓘ explains the term).
- why this rating
- Reproducer-confirmed
- risk area
- Availability
- CVE surface
- None
Where it is
The code the issue lives in — peek the affected function inline to see it in context.
- bin/omarchy-apply-lock (root lock-screen PAM provisioning)
How it's proven
The reproducer — an actual test that drives the real code and shows the issue happening. Run it yourself, or peek the test and the source it covers.
./pocs/crs-260930-g166-c07-c09.sh
Reproduction steps
Technical steps for your engineers to confirm the issue by hand.
./pocs/crs-260930-g166-c07-c09.sh
What protects you, and the fix
What limits your exposure today, and the planned remediation.
What protects you now
sudo env_reset strips exported functions for the non-root arm; the already-root arm (install/upgrade, no sudo) stays exposed
The fix
Unset imported functions before any decision point: eval 'unset -f $(compgen -A function)' under EUID 0. Alternatively run the body via env -i bash --noprofile --norc. Use 'command' for the pinned lookups
Blast radius
If you touch this issue, what else may need re-checking — the requirements it affects and the code and tests that hang off them. Historical view: authored trace links only — automatically derived links aren't reconstructible for past runs.
Touch this finding and you re-check 1 requirements · 1 code files · 1 tests.
- omarchy-apply-lock
- apply-lock-test.sh
Per-requirement evidence
For each requirement this finding touches: the implementing code, verifying tests, and proof obligations that discharge it.
Per-requirement evidence
For each requirement this finding touches: the implementing code, verifying tests, and proof obligations that discharge it.
Evidence trail
The raw evidence manifests behind this finding — superseded by the resolved reproducer above, kept here for traceability.
Evidence trail
The raw evidence manifests behind this finding — superseded by the resolved reproducer above, kept here for traceability.
- proof/evidence/ki-apply-lock-exported-functions-root.yaml
Change history
Every recorded revision of this finding's source file — when it was added, edited, or re-classified, with the diff for each change.
Discussions
Discuss this with the proof team. Nothing changes in your audit automatically — you open a request and a staff member records any outcome inside the thread.