What this actually is.
Technical background, root cause, and affected surface.
In repeater/webgui/settings.c:336, win_log() allocates malloc(sizeof(struct LIST)+strlen(line)) with no integer overflow guard. The addition can overflow if strlen(line) approaches SIZE_MAX. Currently bounded by WI_RXBUFSIZE=153600, preventing exploitable overflow. Latent defect only.
- Vendor
- UltraVNC
- Product
- UltraVNC Repeater
- Severity
- Medium
- CVSS Score
- 5.3
- Status
- Fixed
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
- CWE
- CWE-190: Integer Overflow to Buffer Overflow
From one request
to root shell.
Reproduced in a sandboxed environment. Requires only LAN or WiFi adjacency.
The bug, and the fix.
curr = (struct LIST*)malloc(sizeof(struct LIST) + len); // settings.c:336 // len = strlen(line) from HTTP URI; no overflow guard // Currently bounded: len <= WI_RXBUFSIZE=153600
Root cause: No integer overflow check before malloc size computation. Relies on implicit bounding from HTTP buffer rather than explicit length validation at the allocation site.
When does this fire?
All conditions must be true for the exploit to succeed.
Currently unexploitable via HTTP path (bounded at 153,600 bytes). Would require strlen(line) approaching SIZE_MAX via an alternative code path not present in current source.
What an attacker does to you.
Post-exploitation outcomes mapped to CVSS impact metrics.
Latent defect only. No current exploitable path. If input bound changes: undersized malloc followed by strcpy heap overflow.
Fix it. In this order.
A runbook, not a checklist. Sequence matters — assume compromise before you act.
Add explicit length cap before allocation. Vendor fix: if(len > 512) len = 512; INT_MAX overflow guard added before malloc.
disclose@securin.ioVendors moved in days.
Attackers in hours.
Reconstructed from vendor advisories, CISA bulletins, and Securin research records.
Timeline recorded · Disclosure coordinated by Securin
Cite, verify, go deeper.
Primary sources — NVD, CISA KEV, and machine-readable IoC feed.