On January 29, 2026, Ivanti publicly disclosed two critical Ivanti EPMM zero-days (CVE-2026-1281 and CVE-2026-1340, CVSS 9.8) that expose a high-risk anti-pattern: shell scripts processing untrusted HTTP input inside privileged management infrastructure.
At a high level, these were pre-auth RCEs enabled by unsafe shell evaluation semantics (not just string handling). The root cause traces to Apache RewriteMap (prg) plumbing that piped URL-derived values into Bash scripts (notably /mi/bin/map-appstore-url and /mi/bin/map-aft-store-url). Exploitation hinges on abusing Bash arithmetic expansion and indirect evaluation paths so attacker-controlled input is interpreted in an execution context during logic like timestamp comparisons – turning data into code execution.
Why the urgency matters: CISA added CVE-2026-1281 to the Known Exploited Vulnerabilities (KEV) catalog on January 29 with an accelerated remediation due date of February 1, signaling that U.S. federal civilian agencies must patch under CISA’s binding operational directive BOD 22-01. That strongly signals exploitation was occurring before public disclosure. Watchtowr Labs published a technical breakdown and PoC on January 30, showing how this becomes full appliance compromise on internet-facing MDM/UEM infrastructure – exactly the kind of tier-0 platform that manages corporate mobile fleets.
Operational nuance: Ivanti’s interim RPM mitigations do not persist across version upgrades and must be manually re-applied. A permanent fix is expected in EPMM 12.8.0.0 later in Q1 2026. Secure-by-design takeaway: shell scripting should not be the integration layer between web servers and business logic in privileged infrastructure. This is squarely in CWE-94 (code injection) territory and demonstrates the cascading risk of mixing execution contexts without robust isolation, relying on string manipulation versus structured parsing with strict validation, and assuming indirect evaluation paths are safe. If you run MDM/UEM or any privileged management plane, audit for URL-to-shell, API-to-script, and parameter-to-eval paths. The correct pattern is language-native parsing with strict allowlists – never concatenate untrusted input into execution contexts, period.