CVE-2026-12183: BUK TS-G Authentication Bypass
Critical CVSS (9.8) reachable over network.
| Field | Value |
|---|---|
| CVE ID | CVE-2026-12183 |
| CVSS Score | 9.8 Critical |
| Attack Vector | Network exploitable |
| Authentication Required | None |
| Patch Status | Fixed version not confirmed from accessible vendor source |
TL;DR - BUK TS-G on Linux versions 2.9.1 through 2.10.2 contains a critical unauthenticated admin bypass. - Exposed systems can allow arbitrary attackers to reach privileged configuration functions remotely. - Public PoC exists; no CISA-confirmed in-the-wild exploitation is listed yet.
Vulnerability at a Glance
CVE-2026-12183 affects Nefteprodukttekhnika BUK TS-G Gas Station Automation System on Linux. The vulnerable range, per NVD, is version 2.9.1 through 2.10.2, which should be read as including both 2.9.1 and 2.10.2. The issue is classified as Improper Authentication (CWE-287), with behavior that also aligns with Missing Authentication for Critical Function (CWE-306) because privileged back-end actions do not properly enforce server-side validation.
Operationally, this is not just an exposed admin page problem. The NVD description says a remote attacker can read or modify administrative objects tied to fuel station operations, including user rules, fuel tank gauges, fuel dispensers, relays, cash registers, bank terminals, fuel cards, price displays, customer displays, cash collection, and pricing rules. For defenders, that means the impact spans confidentiality, integrity, and real-world business operations.
What is This Vulnerability?
According to the NVD description, the vulnerable login endpoint is /php/ajax-login.php. It reportedly returns userid=1, which corresponds to administrator access, when it receives any HTTP POST request with arbitrary credentials. The example request pattern given by NVD is:
action=dologinlogin=<any_value>pwd=<any_value>
That alone would be severe, but the second part is what turns this into a full unauthenticated administrative compromise: privileged functionality under /php/ajax-main.php and /modules/* does not validate a server-side session. In practice, that means the system is not merely failing login checks once. It is failing to bind privileged actions to a validated authenticated session, allowing direct access to administrative functions after a trivial request sequence.
Technical Notes
A minimal test pattern based on the NVD description would look like this:
POST /php/ajax-login.php HTTP/1.1
Host: target.example
Content-Type: application/x-www-form-urlencoded
action=dologin&login=test&pwd=test
A vulnerable system is described as returning an administrative identity such as:
userid=1
The follow-on risk is direct access to privileged endpoints such as:
/php/ajax-main.php
/modules/*
Because the public PoC is referenced by NVD at github.com/ciprobe/bukts_auth_bypass, defenders should assume exploit reproduction details are available to attackers even if they have not personally validated that repository content yet.
Who is Affected?
The affected product named in the public record is Nefteprodukttekhnika LLC BUK TS-G Gas Station Automation System running on Linux. The affected version range is explicitly stated as 2.9.1 through 2.10.2. If your asset inventory shows any BUK TS-G Linux deployment in that range, treat it as exposed until proven otherwise.
The hard part for many defenders will be inventory. Systems like fuel station automation platforms are often managed by operations teams, local integrators, or third-party maintainers instead of the central IT patch process. That makes it easy for internet-exposed or flat-network deployments to linger unnoticed. If you do not know the version, the safest assumption is that any reachable BUK TS-G Linux instance may be at risk until you confirm the installed release.
A practical triage table is below:
| Question | Defender Assumption |
|---|---|
| Running BUK TS-G on Linux? | Potentially affected |
| Version is 2.9.1 through 2.10.2? | Affected |
| Version is unknown? | Treat as affected until validated |
| Vendor fix status unknown? | Assume compensating controls are required immediately |
CVSS Score and Severity Context
NVD assigns CVSS 9.8 Critical. The vector string was not returned in the source material available here, so it should not be invented. Still, both the score and the NVD description support a straightforward defensive interpretation: this is network exploitable, requires no authentication, and has high impact because it grants access to privileged administrative functionality.
For practitioners, the most important point is not the exact vector math but the combination of conditions: remote reachability, no credentials needed, and broad control over operational configuration. In OT-adjacent environments, that combination raises the urgency beyond what many teams would assign to a standard web application auth flaw. Changes to pricing rules, dispensing-related configuration, and payment-adjacent settings can create immediate business disruption even without destructive malware.
Exploitation Status
At the time of writing, CISA KEV does not list CVE-2026-12183, so there is no CISA-confirmed in-the-wild exploitation entry for this CVE. That is useful context, but it should not be mistaken for low risk. KEV non-inclusion only means there is no CISA catalog entry confirming active exploitation; it does not mean exploitation is absent.
There is, however, a public GitHub reference in the NVD record: https://github.com/ciprobe/bukts_auth_bypass. That is strong evidence that a public proof of concept exists or that exploit guidance is publicly discussed. The repository content was not fully verifiable from the research note, so defenders should avoid relying on unconfirmed exploit details. But from a risk perspective, a public PoC is enough to assume barrier-to-entry has dropped.
To state the status clearly:
| Signal | Status |
|---|---|
| Confirmed exploitation in the wild | Not confirmed by CISA KEV |
| Public PoC available | Yes, GitHub reference present in NVD |
| KEV listed | No |
| Fixed version confirmed | No, not verified from accessible vendor source |
What Defenders Should Do Next
First, identify whether any BUK TS-G Linux instances exist in your environment and whether they are in the affected range 2.9.1 through 2.10.2. If you cannot quickly determine the version, isolate reachable instances as though they are vulnerable. This CVE is severe enough that uncertainty should not delay containment.
Second, hunt for recent access to the referenced paths and for unexpected administrative changes affecting pricing, payment-related devices, displays, dispensers, relays, or tank gauges. Because public exploit material is referenced, assume opportunistic scanning and low-skill exploitation are plausible. If you find suspicious access, preserve web logs, reverse proxy logs, and system configuration snapshots before making changes.
For additional information on authentication mechanisms, you can check our article on How Does JWT Authentication Work. Also, learn more about Network Segmentation to enhance your security posture.
How to Detect It
Detection should focus on two behaviors: suspicious login requests to /php/ajax-login.php and subsequent access to /php/ajax-main.php or /modules/* without a normal authenticated workflow. Because the vulnerability is described as accepting arbitrary credentials, repeated login failures may not appear in the normal way. Instead, you may see successful or unusual responses tied to nonsense usernames and passwords.
You should also look for configuration changes in short succession after web requests from unfamiliar IP addresses. Any changes to dispensers, relays, gauges, registers, pricing, or display settings should be treated as high-signal events. In environments where application logs are weak, web server access logs and reverse proxy telemetry may be your best initial source.
Technical Notes
Example web log indicators to hunt for:
POST /php/ajax-login.php HTTP/1.1
POST /php/ajax-main.php HTTP/1.1
GET /modules/
POST /modules/
A simple grep across access logs:
grep -E '(/php/ajax-login\.php|/php/ajax-main\.php|/modules/)' /var/log/nginx/access.log /var/log/apache2/access.log 2>/dev/null
Look for arbitrary credentials posted to the login endpoint:
grep 'POST /php/ajax-login.php' /var/log/nginx/access.log | grep 'action=dologin'
If you are normalizing HTTP logs into Splunk, a starting query could be:
index=web (uri_path="/php/ajax-login.php" OR uri_path="/php/ajax-main.php" OR like(uri_path, "/modules/%"))
| stats count min(_time) as first_seen max(_time) as last_seen values(src_ip) as src_ip values(http_method) as methods by host, uri_path, status
For Elastic / KQL:
url.path : ("/php/ajax-login.php" or "/php/ajax-main.php" or "/modules/*")
If you run a reverse proxy or WAF in front of the application, consider a temporary high-confidence alert on:
POST /php/ajax-login.php with body containing action=dologin
especially when followed by requests to /php/ajax-main.php or /modules/ from the same source IP within a short time window.
Mitigation and Patching
The most important constraint here is that the fixed version number is not confirmed from the accessible source material. The vendor reference listed by NVD could not be validated from the research path due to a TLS certificate and hostname mismatch, so it would be inaccurate to name a fixed release. Therefore, defenders should state the situation plainly in internal advisories: affected versions are 2.9.1 through 2.10.2, and the fixed version is currently unverified from the available primary source.
In the absence of a confirmed fix version, assume compensating controls are required immediately. If the system is internet exposed, remove direct public access. Restrict reachability to a management network, VPN, or jump host with strong access control. If the platform cannot be patched immediately, isolate it from untrusted networks and monitor it closely for administrative access attempts and configuration changes. Because this is an unauthenticated issue, simple credential rotation is not a sufficient mitigation.
Technical Notes
If BUK TS-G is behind NGINX, a temporary block rule for the known paths may reduce exposure while you work with the vendor or integrator:
location ~ ^/(php/ajax-login\.php|php/ajax-main\.php|modules/) {
allow 10.0.0.0/8;
allow 192.168.0.0/16;
deny all;
}
Apply and reload:
sudo nginx -t && sudo systemctl reload nginx
If Apache is in use, a temporary access restriction could look like:
<LocationMatch "^/(php/ajax-login\.php|php/ajax-main\.php|modules/)">
Require ip 10.0.0.0/8 192.168.0.0/16
</LocationMatch>
Reload Apache:
sudo apachectl configtest && sudo systemctl reload apache2
If you need an immediate host firewall restriction on Linux:
sudo iptables -A INPUT -p tcp --dport 80 -s 10.0.0.0/8 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -s 192.168.0.0/16 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j DROP
For upgrade planning, use your package or deployment inventory to identify installed versions, but do not assume a package upgrade path exists unless your vendor documents it. Example local version checks on Linux might include:
dpkg -l | grep -i buk
rpm -qa | grep -i buk
find /opt /usr/local -maxdepth 3 -type f | grep -i buk
If the vendor provides a repository-based update method, validate the repository and release notes out of band before issuing an upgrade. Since the fixed version is unknown here, the correct instruction is: contact the vendor or integrator for the first release that remediates CVE-2026-12183, then test and deploy that exact build.
References
- NVD CVE record: https://nvd.nist.gov/vuln/detail/CVE-2026-12183
- CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- GitHub PoC reference listed by NVD: https://github.com/ciprobe/bukts_auth_bypass
- EUVD corroborating entry: https://euvd.enisa.europa.eu/enisa/EUVD-2026-10493
- CWE-287: https://cwe.mitre.org/data/definitions/287.html
- CWE-306: https://cwe.mitre.org/data/definitions/306.html
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.