CVE-2026-102834: 
Java vulnerability analysis and mitigation

CVE-2026-102834 is an integer overflow vulnerability in JavaCV's IPCameraFrameGrabber component that causes a permanent infinite-loop denial of service. It affects all versions of org.bytedeco:javacv prior to 1.5.14 (Maven). The vulnerability was first published on July 25, 2026, and added to the GitHub Advisory Database on October 16, 2026. It carries a CVSS v3.1 base score of 7.5 (High) (Github Advisory).

The root cause is a 32-bit signed integer overflow (CWE-190) in the ensureBufferCapacity(int) method within IPCameraFrameGrabber.java. The method parses the Content-Length header from a multipart MJPEG HTTP stream verbatim — with no upper-bound validation — and repeatedly doubles a 32-bit int capacity variable until it meets or exceeds the attacker-supplied value. When desiredCapacity is in the range 1,073,741,825–2,147,483,647, the doubling causes the variable to overflow to Integer.MIN_VALUE, then wrap to 0, after which 0 * 2 == 0 permanently, and the loop condition 0 < desiredCapacity is always true, creating an unbreakable infinite loop. Because the loop contains no I/O, no blocking calls, and no InterruptedException check, it cannot be interrupted via Thread.interrupt() and ignores any configured socket timeouts. A public PoC server (Python) and client (Java) are included in the advisory (Github Advisory, Patch Commit).

Successful exploitation permanently hangs the frame-grabbing thread at 100% CPU with no exception, timeout, or recovery path — the only remedy is killing the JVM process externally. There is no confidentiality or integrity impact; the sole consequence is a high availability impact on the affected application. In video-surveillance or monitoring backends that spawn a grabber thread per camera or client, repeated exploitation can exhaust all available CPU cores and threads, causing a broader application-level denial of service (Github Advisory).

A public proof-of-concept is included in the GitHub Security Advisory, consisting of a minimal Python MJPEG server and a Java client that reproduce the hang with a single crafted HTTP response header. No authentication, JPEG payload, or actual data transfer is required — only the malicious Content-Length header value (any integer in the range 1,073,741,825–2,147,483,647) is needed. The attack is network-accessible, requires no privileges, and no user interaction. The EPSS score is 0.0 and there is no evidence of in-the-wild exploitation or CISA KEV listing at this time (Github Advisory).

1. Identify target: Locate applications using org.bytedeco:javacv versions < 1.5.14 that consume MJPEG streams from IP cameras over plaintext HTTP (e.g., http://host/videostream.cgi).
2. Position for attack: Either control a malicious camera endpoint the target application connects to, or perform a network man-in-the-middle (MITM) attack on the plaintext HTTP stream between the application and a legitimate camera.
3. Craft malicious MJPEG response: Set up a TCP listener (e.g., using Python's socket module) that accepts the client's HTTP request and responds with a multipart MJPEG boundary header containing an oversized Content-Length value in the range 1,073,741,825–2,147,483,647 (e.g., Content-Length: 2000000000).
4. Trigger the overflow: When the target application calls grab() or grabBufferedImage(), IPCameraFrameGrabber.readImage() parses the attacker-controlled Content-Length and passes it to ensureBufferCapacity(), triggering the integer overflow and infinite loop.
5. Achieve DoS: The frame-grabbing thread spins at 100% CPU indefinitely. Repeat connections to exhaust all grabber threads/CPU cores for a broader denial of service (Github Advisory).

• Process: Java process (JVM) consuming a sustained 100% CPU on one or more cores with no reduction over time; thread dump showing a thread permanently stuck in org.bytedeco.javacv.IPCameraFrameGrabber.ensureBufferCapacity() or readImage().
• Network: Inbound or proxied HTTP responses to the application containing a Content-Length header with a value greater than 1,073,741,824 in a multipart MJPEG stream; connections from unexpected or untrusted IP addresses to camera stream endpoints.
• Logs: Application logs showing grab() or grabBufferedImage() calls that never return or time out; absence of expected frame-processing log entries after a camera connection is established; JVM thread dump logs indicating a non-progressing loop in IPCameraFrameGrabber.

Upgrade org.bytedeco:javacv to version 1.5.14 or later, which introduces a MAX_CONTENT_LENGTH constant (64 MB) and rejects any Content-Length outside the range (0, 67108864] with an IOException, and also changes the ensureBufferCapacity loop variable to long to prevent overflow (Github Advisory, Patch Commit, Release 1.5.14). As a workaround prior to patching, restrict IPCameraFrameGrabber usage to fully trusted, authenticated, and encrypted (HTTPS/TLS) camera endpoints to eliminate the MITM attack surface. Additionally, consider wrapping grabber threads with an external watchdog that kills and restarts threads exceeding a CPU time threshold.

The vulnerability was reported by security researcher tinyb0y and published by project maintainer saudet (Samuel Audet) via GitHub Security Advisory on July 25, 2026. No significant broader media coverage or notable public researcher commentary beyond the advisory itself has been identified at this time (Github Advisory).