WebSphere Application Server EUVD-2026-77803

Exploitation requires input controlled by the attacker to be written, without CR/LF neutralization, into the WebSphere Application Server administrative log - concretely, a reachable request path (HTTP request line, header, or parameter) whose value is echoed into the admin/SystemOut log, and a downstream log parser or human operator that treats line breaks as record boundaries. Per the supplied CVSS vector (AV:N/PR:N/UI:N), no authentication and no user interaction are required for the vulnerable code path, but remote unauthenticated reachability itself is a precondition: deployments that firewall the administrative console and admin endpoints to internal management networks, or that sit behind a reverse proxy which strips control characters, are materially less exposed. What limits impact: C:N and A:N mean no data disclosure and no denial of service, the flaw cannot execute code or alter application state, and forging is only meaningful where the admin log is trusted for monitoring, compliance, or forensics. The input data does not identify the specific vulnerable endpoint or logging component, so defenders should not assume any particular URL family is safe.

The signals here are consistent but bounded: CVSS 3.1 gives 5.3 with AV:N/AC:L/PR:N/UI:N, meaning the exploit is remotely reachable, requires no authentication, no user interaction, and no special conditions beyond the input path reaching the admin log; scope is unchanged and only integrity is rated Low (C:N/I:L/A:N). CISA's SSVC categorizes exploitation as 'none' but automatable 'yes' with technical impact 'partial', which matches a low-skill, scriptable log-forging primitive rather than a compromising exploit. There is no KEV entry and no public exploit identified at time of analysis, and no EPSS score was supplied with this record - that absence is notable because it means the probability-of-exploitation signal cannot be cross-checked against the KEV and SSVC signals. The practical takeaway is that this is an integrity and audit-fidelity issue: even a mid-sized municipal IT team in sanok that relies on WebSphere admin logs for compliance evidence should treat log integrity as a real (if non-urgent) exposure, while teams not exposed to untrusted input paths will see negligible risk. Note that log-forging severity scales with what the logs are used for - automated detections, compliance evidence, and forensic timelines - not with the 5.3 base score alone.

An unauthenticated attacker crafts an HTTP request whose URI, header, or parameter value contains encoded CRLF sequences plus text that mimics a legitimate WebSphere administrative log line, and sends it to a reachable endpoint that echoes that input into the admin log. The server writes the unsanitized value, and the injected line breaks cause downstream log parsers to record an entirely fabricated entry - for example a fake administrative login or configuration change. With AC:L/PR:N/UI:N per the CVSS vector, this can be scripted and repeated to pollute the audit trail; no public exploit code has been identified, so this remains a low-sophistication, opportunistic technique rather than an active campaign.