CVE-2026-10067
Stack-Based Buffer Overflow in Shibby Tomato
Publication date: 2026-05-29
Last updated on: 2026-05-29
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| shibby_tomato | 1.28 | * |
| shibby | tomato | 1.28 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-119 | The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data. |
| CWE-121 | A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function). |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-10067 is a stack-based buffer overflow vulnerability found in the sub_90F0 function of the multimon.cgi component in Shibby Tomato firmware version 1.28.
The vulnerability arises because the function copies attacker-controlled UPS response fields into fixed-size stack buffers without proper bounds checking, allowing an attacker to overflow the buffer.
Specifically, two unsafe write paths exist: a newline-terminated byte-copy loop and an unbounded sscanf operation, which can be exploited by spoofing a UPS endpoint and sending oversized fields such as DATE, ITEMP, LINEV, MINLINEV, or MAXLINEV.
This causes memory corruption beyond the intended buffer boundary, potentially leading to process crashes, stack data corruption, and control-flow hijacking.
How can this vulnerability impact me? :
This vulnerability can be exploited remotely to cause a stack-based buffer overflow, which may lead to process crashes and corruption of stack data.
More critically, it can allow an attacker to hijack the control flow of the affected device, potentially executing arbitrary code or causing denial of service.
Since the affected product is no longer supported, patches or fixes may not be available, increasing the risk if the device remains in use.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for crashes or abnormal behavior in the multimon.cgi process on Shibby Tomato 1.28 devices, especially when handling UPS response data.
Since the vulnerability involves a stack-based buffer overflow triggered by malformed UPS response fields, detection could involve capturing and analyzing network traffic to identify suspicious or oversized UPS response fields such as DATE, ITEMP, LINEV, MINLINEV, or MAXLINEV.
Debugging tools like GDB can be used on the device or firmware emulation (e.g., QEMU) to observe process crashes or stack corruption in the multimon.cgi component.
Specific commands might include:
- Using tcpdump or Wireshark to capture network traffic on the device to inspect UPS response packets for abnormal or oversized fields.
- Using GDB to attach to the multimon.cgi process to monitor for crashes or memory corruption during UPS response parsing.
- Checking system logs for crashes or errors related to multimon.cgi.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include discontinuing the use of Shibby Tomato 1.28 firmware since it is no longer supported and is vulnerable to this stack-based buffer overflow.
Migrating to a supported and actively maintained firmware such as FreshTomato is recommended to avoid this and other vulnerabilities.
Additionally, restricting or filtering network access to the vulnerable multimon.cgi service, especially from untrusted sources, can reduce the risk of remote exploitation.
Monitoring for unusual UPS response traffic and disabling or isolating UPS monitoring features that rely on multimon.cgi may also help mitigate exposure.