Fortra BoKS Manager EUVD-2026-90849

Requires an authenticated KSL client able to reach the boks_ksllogsd daemon and send a KSL start message (PR:L - not exploitable by unauthenticated attackers). The attacker must place an oversized yet OpenSSL-recognized checksum/digest name in the MD field of that message. Exploitation is limited to deployments of Fortra BoKS Manager/BoKS Server running the boks_ksllogsd logging daemon; the write content is constrained to valid digest-name strings, which bounds corruption and makes denial of service the realistic outcome rather than code execution.

This is a genuine memory-corruption bug (CWE-787 heap out-of-bounds write) but a moderate-priority one in practice. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, 6.5) is internally consistent with the description: network-reachable, low-complexity, but requiring an AUTHENTICATED KSL client (PR:L) and yielding availability-only impact. The vendor scopes impact to A:H with C:N/I:N, which is credible - the attacker only controls the written data to the extent that it must be a valid, OpenSSL-recognized digest name copied past a fixed 16-byte context field, so the corruption content is constrained and the realistic outcome is a daemon crash/DoS rather than reliable code execution. No EPSS score, no CISA KEV listing, and no public exploit code are present in the provided data, so there is no evidence of active or automated exploitation - this is no public exploit identified at time of analysis. The authentication precondition (must already be a legitimate KSL client) meaningfully narrows the attacker population and lowers real-world urgency relative to the 6.5 base score. No conflicting signals: the network vector is consistent with the KSL protocol described, and nothing in the description contradicts the vector.

An attacker who already holds valid credentials as a KSL client connects to the boks_ksllogsd daemon and sends a KSL start message whose MD (checksum algorithm) field contains an oversized but OpenSSL-recognized digest name. Because the daemon validates only that OpenSSL recognizes the name and not that it fits the fixed 16-byte checksum context, copying the name writes past the end of the heap allocation, corrupting adjacent heap memory and crashing the logging daemon. No public proof-of-concept is identified in the available data.