CVE-2026-66463

The EPSS-CVSS gap in this CVE — a 7.5 CVSS paired with an EPSS of just 0.00303 — should concern you more, not less. The standard interpretation would be 'low exploitation probability, deprioritize.' But this disconnect reveals something important: EPSS measures opportunistic scanning activity against internet-facing targets, and supply chain tooling like iCARRY often sits outside that visibility layer entirely. The unauthenticated data access is the key. If exploitation requires no credentials, the barrier to opportunistic attackers is trivial — which should drive EPSS upward, not keep it flat. The fact that it stays low tells you the real constraint isn't exploit complexity; it's opportunity. The system isn't being found by mass scanners, likely because it lives behind corporate perimeters, inside trusted network segments, or in the kind of obscure logistics infrastructure that doesn't register in attacker telemetry. That's the concern: sophisticated actors don't need to scan for this. They find it through partner networks, through compromised vendors, through the kind of manual reconnaissance that doesn't show up in EPSS data. This software bridges inventory systems, shipping APIs, and ERP integrations — exactly the poorly-monitored pivot points that attackers target after they've gained initial access elsewhere. Low EPSS measures opportunistic exploitation; it says nothing about whether this is already in a threat actor's target inventory. The deeper problem: unauthenticated endpoints in supply chain tooling rarely appear in isolation. This category of software follows a documented pattern — built fast to meet operational deadlines, IoT connectivity retrofitted onto legacy systems, authentication inconsistently applied because 'it's only internal.' This CVE likely signals a class-level architectural flaw, not an isolated bug. Other endpoints in the same codebase probably share the same exposure. What you should do: First, verify whether you run any iCARRY instance at version 2.9 or earlier. Second, determine whether authentication was deliberately omitted in the original API design or whether a previous auth layer was removed during refactoring — that distinction reveals whether this is a design philosophy mismatch or a simple code bug. Third, map the downstream connections: what inventory systems, shipping APIs, or ERP integrations does this touch? Assume lateral movement has already occurred if you discover this during incident response rather than proactively. Fourth, treat this as a forcing function to audit the entire codebase for other unauthenticated endpoints — there are almost certainly more.

Reviewed through automated stages and approved by a human before publication.