Apache Cocoon EUVD-2026-104912

Exploitation requires that the Apache Cocoon instance uses the SQL processor or the sql:/esql: logicsheets AND that those pipelines incorporate attacker-controllable input without neutralization - a Cocoon deployment that does not use SQL logicsheets is not exploitable via this flaw. The vulnerability affects all versions and will never be patched because the project is retired; the only limiting/mitigating factors are not using the SQL logicsheets, restricting instance access to trusted users, or migrating off Cocoon entirely. Realistic exposure also depends on whether the vulnerable pipeline is reachable by untrusted users rather than being internal-only.

This is a CWE-89 SQL injection in Apache Cocoon affecting all versions, confirmed by the Apache vendor advisory. No CVSS vector was provided by NVD or the vendor, so attack-vector/complexity/privilege signals cannot be read directly from a scored vector and are inferred below from the description. There is no EPSS score, no CISA KEV listing, and no public POC referenced in the available data, so the three exploitation-pressure signals are all either absent or negative - this points to a theoretical/latent risk rather than confirmed widespread or targeted exploitation. The most important risk modifier is that Apache Cocoon is officially RETIRED with no fix planned ever; defenders cannot patch and must mitigate by migrating off the product or restricting access to trusted users. Weighing these signals together: the technical impact of a SQL injection is high (potential full database read/write), but real-world priority is tempered by the product's retired status and small modern footprint and by the absence of any exploitation evidence. Treat as a high-technical-impact but low-exploitation-pressure issue; the permanent lack of a patch makes it a durable configuration-management problem rather than an urgent emergency for most environments.

An attacker sends a crafted HTTP request to a Cocoon application whose pipelines use the SQL processor or the sql:/esql: logicsheets with unsanitized request parameters. Because input is not neutralized, the attacker injects arbitrary SQL that the backend database executes, enabling data theft or modification. No public exploit code is identified at time of analysis, and exploitation requires that the target actually uses the vulnerable SQL logicsheets/processor.