I’m Danilo Erazo, an Independent Automotive Security Researcher. In February 2025, I had the opportunity to conduct hardware hacking and software reverse engineering analysis on a Calix GigaCenter ONT, through which I discovered five critical zero day vulnerabilities affecting multiple Calix GigaCenter models. These routers are used specifically in the American Continent (USA, Ecuador, Argentina, Belize, Bolivia, Brazil, Costa Rica, El Salvador, Guatemala, Mexico, Panama). In this post, I share the reconnaissance phase of the analysis, the discovery of five zero day vulnerabilities, and most important, the hacktivism/disclosure process I carried out to get patch by the manufacturer (CVE-2025-53913, CVE-2025-53914, CVE-2025-7635, CVE-2025-54083, CVE-2025-54084), for these critical issues , conducted responsibly and transparently fully aligned with disclosure policies and always from the standpoint of an ethical hacker committed to user safety.
> RECONNAISSANCE PHASE
But what is an ONT? An Optical Network Terminal (ONT) is the device provided by your Internet Service Provider (ISP) when you have a fiber optic connection at home. It acts as the endpoint that converts optical signals into data your home network can use.
The first step I took was to search for previously reported CVEs related to this router model. What caught my attention was that no CVEs existed, despite this being a very old and widely deployed device. That struck me as unusual, so I decided to perform a deep technical analysis of the router.
Tools used: Bus Pirate, interface FTDI, Multimeter, programmer CH341a, programmer XGecu T48 (TL866II-3G), Ghidra
Component Identification
In this case, the GigaCenter ONT also functions as a home router, meaning that both the WAN fiber optic connection and the LAN/WLAN router interfaces are integrated into the same device. On the front side of the ONT board, I identified that the Broadcom BCM68380 SoC handles the WAN fiber optic link, while the Quantenna QT3840BC SoC manages the LAN/WLAN connections, as shown below.
Components summary:
| Component | Description |
| QT2518B | RF Transceiver 802.11ac/n 4×4 MIMO |
| QT3840BC | Quantenna Baseband SoC 802.11ac |
| W631GG6MB-12 | DRAM 1GB DDR3 SDRAM |
| W632GU6MB-12 | DRAM 2GB DDR3L 1.35V SDRAM |
| GD25D05BT1G | Flash memoryNOR 65Kbit SPI – Quantenna Firmware |
| U74HC164G | 8-BIT SERIAL-IN AND PARALLEL-OUT SHIFT REGISTER |
| BCM68380 | Broadcom ONT SoC |
| MX30LF2G189C-TI | Memoria flash NAND SLC NAND 3V 2Gbit x8 TSOP-48 4BitETC –Firmware Broadcom |
Finally, the FCC-ID of this router is https://fccid.io/2ABLK-8X4G-1.
Firmware extraction and analysis
– GD25D05BT1G Extraction
GD25D05BT1G – SPI Connection
The GD25D05BT1G memory was identified as containing the Quantenna SoC firmware, so the firmware was extracted using the very famous programmer CH341a. Once the binary was obtained, the JFFS2 file system was extracted. Information about this is shown below:
The entropy of the binary shows that the binary is mostly compressed:
Finally, the jffs2 file system was extracted:
– NAND MX30LF2G189C-TI Extraction
MX30LF2G189C SPI connection and internal parts
Desoldering the NAND flash:
Using the XGecu T48 (TL866II-3G) programmer to dump the firmware:
Extracted firmware:
I discovered that the firmware stored in the NAND flash uses the ARCompact architecture, which is an uncommon and rarely used architecture. Its main features are:
- Loaded into a specific address in memory on boot by a bootloader.
- Content: Initialization code and Hardcoded constants:
– Router with 2 IPs by default: e=192.168.1.1:ffffff00 h=192.168.1.100.
– Broadcom kernel: bcm963xx_fs_kernel.
– LE9540 Broadband Gateway SLIC – Dual-channel SLIC/SLAC (Subscriber Line Interface/Access Circuit) Fiber ONT (Optical Network Terminals).
Identifying debugging interfaces
UART interface corresponding to the Quantenna SoC was discovered, the baud rate of this interface is 115200 bps:
UART interface corresponding to the Broadcom SoC was discovered, the baud rate of this interface is 115200 bps:
> ZERO DAYS
In February 2025, I discovered several critical zero-day vulnerabilities through a combination of hardware hacking and software reverse engineering. The vulnerabilities identified are as follows:
1) Excessive Privileges in Calix Gigacenters ONT allows unauthenticated root access via UART interface (Quantenna SoC)
UART Connection with Bus Pirate:
Affected devices: Calix GigaCenter ONT 844E, 844G, 844GE, 854GE, 812G, 813G, and 818G
Check more details in the CNA advisory: https://fluidattacks.com/advisories/forty
2) Excessive Privileges in Gigacenters ONT allows unauthenticated root access via UART interface (Broadcom SoC)
UART Connection with FTDI interfaz (Bus Pirate had issues to get a legible shell):
Affected devices: Calix GigaCenter ONT 844E, 844G, 844GE, 854GE, 812G, 813G, and 818G
Check more details in the CNA advisory: https://fluidattacks.com/advisories/sheivi
3) Unauthenticated Telnet Access in Calix Gigacenter ONT grants administrative access
An internal interface is discovered in the boot proccess of the ONT Broadcom SoC. This new interface has Telnet enabled and is the interface of the LAN/WLAN link.
Affected devices: Calix GigaCenter ONT 844E, 844G, 844GE and 854GE.
Check more details in the CNA advisory: https://fluidattacks.com/advisories/sal
4) Sensitive Information Disclosure in ONT GigaCenter Firmware
WPA PSK in plain text and weak web credentials detected:
Affected devices: Calix GigaCenter ONT 844E, 844G, 844GE and 854GE.
Check more details the CNA advisory: https://fluidattacks.com/advisories/rocola
5) Command Injection in Calix Gigacenter ONT
I discovered the arquitecture of the web server binaries (mini_httpd and php-cgi.cgi) of the Quantenna firmware is ARCompact ARC700 arquitecture, as shown below:
But wait, what is ARCompact ARC700 arquitecture and how it works?
Some features of this arquitecture:
- ARC (Argonaut RISC Core) processors is developed by Synopsys.
- Development & Debugging: Synopsys ARC MetaWare Development Toolkit, the MetaWare Development Toolkit offers a complete product solution to effectively support the development, debugging and tuning of your embedded applications for the ARC processor. Lite version is for free.
- Load/Store RISC architecture: Operations are performed on registers, not directly in memory.
- 16-bit and 32-bit mixed-length instruction set: Code density similar to 16-bit MCUs but performance of 32-bit processors.
- 32 general-purpose registers (GRs): (r0–r31), with register windows for fast context switching.
- Registers for Looping: LP_START, LP_END, LP_COUNT
- Configurable instruction set extensions: Custom instructions can be added for application-specific acceleration.
- Efficient code density: Compact encoding reduces memory footprint.
- 32-bit address and data space: Supports modern embedded applications.
- Support for DSP operations: Multiply-accumulate (MAC) and other DSP like instructions.
- Optional hardware divide and multiply: Performance boost for arithmetic-heavy applications.
- Fast interrupt response: Through multiple register banks and minimal cycles for entry/exit.
- Low power consumption design → Targeted for embedded and real-time systems.
- Used in embedded devices such as SoCs, storage controllers, automotive systems, digital audio players, modems, and IoT devices: Where power efficiency and compact code size are crucial.
You can check more about ARCompact Instruction Set Arquitecture in their official Programmer’s Reference:
Reverse engineering the mini_httpd binary, which is compiled for the ARCompact architecture, is not straightforward. Tools like IDA Free, Binary Ninja (licensed), and Ghidra (free) do not support this architecture by default. Therefore, we are left with three options:
- With IDA Pro (paid)
2. With a Binary Ninja plugin (free)
Using the plugin: https://github.com/nullableVoidPtr/binja-arcompact by Avery Warddhana (@nullablevoidptr)
3. With Ghidra forked (free)
Using the Ghidra forked for ARCompact architecture: https://github.com/niooss-ledger/ghidra.
Ghidra fork:
You can read more aboout this Ghidra fork in the following paper: https://www.sstic.org/media/SSTIC2021/SSTIC-actes/analyzing_arcompact_firmware_with_ghidra/SSTIC2021-Article-analyzing_arcompact_firmware_with_ghidra-iooss.pdf
I decided to use Ghidra, and after overcoming numerous errors, I successfully built a fork of Ghidra with support for the ARCompact architecture on Windows:
The Ghidra build can be found at the following path: ghidra/build/dist/
Finally, when I run ghidraRun.bat, the ARCompact architecture becomes available:
Let’s start reversing the mini_httpd binary:
I found the mini_httpd version is 1.19 (very older version):
This web server is developed by ACME:
I didn’t find anything interesting in the web server binary, so I decided to reverse engineer the php-cgi.cgi binary instead. During the analysis, I discovered numerous strings such as “cannot execute a blank command,” “command,” “configure command,” and others, as shown below:
The first thought that came to mind was “Command Injection.” To understand this better, let’s review the web architecture when PHP-CGI is used, which is as follows:
The arquitecture works in the following way:
- A web server (mini_httpd) receives the client’s HTTP request.
- If the request is for a PHP script, the server forwards it to the PHP-CGI binary (Common Gateway Interface).
- PHP-CGI runs the script as a separate process, executes the PHP code, and produces output (usually HTML).
- The output is sent back to the web server, which then returns it to the client’s browser.
Therefore, in short: Client → Web Server → PHP-CGI (executes script) → Web Server → Client
If there is a command injection vulnerability, I would need to examine the PHP scripts that handle the Common Gateway Interface (CGI). And indeed, after searching through all the PHP scripts for strings related to “cannot execute a blank command,” “command,” and “configure command,” I discovered an interesting file named tools_command.php:
In this file, I found that user input is passed directly to the PHP function shell_exec():
This PHP code is extremely dangerous because it lacks any input sanitization, meaning that an attacker could potentially execute commands like rm -rf, which could completely compromise or destroy the system.
But it gets worse, if you pay attention, the result is stored in the PHP variable $tmp, which is later displayed to the user using , as shown below:
I immediately powered on the router, tested for this functionality or bug, and executed the command injection using “cat /etc/passwd” and voilà! It worked:
However, you need to be a “super” user on the web interface to exploit this vulnerability. But don’t worry—remember the fourth vulnerability, “Sensitive Information Disclosure in ONT GigaCenter Firmware”. In that case, the default password for the “super” user is also “super” xD. I automated this authenticated RCE into an unauthenticated one in this exploit: https://github.com/revers3everything/rce-calix-gigacenter
Affected devices: Calix GigaCenter ONT 844E, 844G, 844GE, and 854GE.
Check more details in the CNA advisory: https://fluidattacks.com/advisories/bacalao
> DISCLOSURE STORY TIMELINE
February 10–16, 2025: The security research was conducted.
February 16: The vulnerabilities discovered were not listed in the MITRE CVE database. I reported them to the manufacturer (Calix) via their official vulnerability disclosure platform.
February 18: Calix responded, stating that the affected router model, along with other devices in the same product line, had reached End of Life (EOL). Since they are no longer manufactured, “it is not possible to patch” the vulnerabilities. The company confirmed they would not be issuing a patch, although these routers will continue to receive support until 2027/2028 (2 o 3 years more).
March: I obtained data indicating that over 60,000 units of this specific ONT Gigacenter router model are still in use in my country alone, and that hundreds of thousands remain deployed worldwide, specifically in the American Continent (USA, Ecuador, Argentina, Belize, Bolivia, Brazil, Costa Rica, El Salvador, Guatemala, Mexico, Panama), you can verify this information through internet. Recognizing the severity and scale of the issue, I resumed communication with Calix through the original email chain.
May 7: I sent a detailed follow up email to Calix emphasizing the critical risk these zero day vulnerabilities pose, especially given the large number of devices still in operation. I pointed out the inconsistency in claiming to support the devices until 2027/2028 while refusing to patch major security flaws. I offered assistance in developing a fix, and informed them that if they did not collaborate, I would be forced to publicly disclose the vulnerabilities.
May 23: After several emails and escalation attempts, Calix finally responded positively, confirming that they would develop and release a firmware update to address the vulnerabilities. This was a major milestone, and a significant achievement resulting directly from my persistence and communication.
June 10 – July 2: I collaborated with Calix by providing additional technical details about the vulnerabilities and proposed remediation strategies to aid in the development of the patch.
July 3: I emailed Calix Security again, requesting that they handle the CVE assignment process. I offered to manage the CVE creation if they preferred. I did not receive any response.
July 11: I independently contacted CNA (CVE Numbering Authority) Fluid Attacks to request five CVEs for the zero day vulnerabilities.
July 15: I informed Calix Security that I had initiated the CVE process with the CNA. Calix responded stating they do not pursue CVEs due to company policy. According to them, Calix does not authorize direct-to-consumer sales of these devices, instead, they are sold via service providers (BSPs) who lease them to end-users. Consequently, they argue that there is no publicly accessible update mechanism and, historically, they have chosen not to disclose vulnerabilities affecting these devices. (This security process is very scary)
July 18: The firmware patch for the five zero day vulnerabilities was officially released!! 🙂 to Calix customers through an internal advisory. This marked the successful resolution of the core technical issues.
July 21: The CNA reserved the five CVEs and contacted Calix to gather further technical details and coordinate the responsible disclosure process.
July 29: I discovered that another critical vulnerability had been reported earlier in 2025 but was never assigned a CVE or publicly disclosed. This raised serious concerns about Calix’s vulnerability management process. I realized I was the first researcher to conduct a deep hardware hacking analysis on the ONT Gigacenter router series. Previous research had only addressed a network level vulnerability, not deep level analysis. I sent a follow up email to Calix criticizing their handling of vulnerabilities, particularly their failure to assign CVEs or inform me of prior reports. I reiterated that CNA, not Calix, determines the publication of CVEs.
July 21 – September 1: Ongoing communications were held between the CNA, Calix Security, and myself to finalize the CVE documentation and disclosure timeline.
September 9: Finally, after 7 months, the five CVEs related to the zero day vulnerabilities were officially published, concluding the coordinated disclosure process.
Published CVEs
CVE-2025-53913: Excessive Privileges in Calix Gigacenters ONT allows unauthenticated root access via UART interface (Quantenna SoC) – https://www.cve.org/cverecord?id=CVE-2025-53913
CVE-2025-53914: Excessive Privileges in Gigacenters ONT allows unauthenticated root access via UART interface (Broadcom SoC) – https://www.cve.org/cverecord?id=CVE-2025-53914
CVE-2025-7635: Unauthenticated Telnet Access in Calix Gigacenter ONT grants administrative access – https://www.cve.org/cverecord?id=CVE-2025-7635
CVE-2025-54083: Sensitive Information Disclosure in ONT GigaCenter Firmware – https://www.cve.org/cverecord?id=CVE-2025-54083
CVE-2025-54084: Command Injection in Calix Gigacenter ONT – https://www.cve.org/cverecord?id=CVE-2025-54084
> HOW TO PATCH
This issue is resolved in the R12.2.13.4 patch available to authorised users. Subscribers with concerns about the security of the ONT servicing their premises should contact their BSP to push the update, as these devices are not licensed to consumers.
So, if your company or household uses these ONT routers, you should request the patch from your ISP or BSP. It is the provider’s responsibility to deploy the update on affected devices. However, if you purchased these routers online or through unofficial sources, you won’t be able to obtain the patch through official channels.
Acknowledgments:
Calix Security – For agreeing to develop a firmware patch after recognizing the serious risk these vulnerabilities posed to hundreds of thousands of users worldwide, especially given that these devices will remain in support at least 2028.
CNA Fluid Attacks – For managing the CVE assignment process, facilitating clear communication with Calix, and ensuring that the responsible disclosure process was properly followed.
About the Author
