This is less a skeleton key than a valet ticket machine that trusts whatever ticket number you type in
The disclosure describes an *authorization bypass through a user-controlled SQL primary key* in Akmer Bilişim's parking and access-control software stack, which likely means a web endpoint accepts an attacker-supplied record ID and then reads or updates rows it should have authorization-checked first. That can translate into arbitrary access to ticket, vehicle, customer, balance, or access-event records without needing a classic quote-based SQL injection payload. Publicly indexed sources available at assessment time do not clearly publish an exact affected version range or fixed build, so treat Akmer/TeknoPass web components present in your environment as potentially in scope until the vendor publishes build-level guidance.
The vendor's 9.8 Critical score assumes a wide-open, internet-exposed, unauthenticated path to full compromise across confidentiality, integrity, and availability. Reality is narrower: the title points more toward an *IDOR/row-level authorization failure with SQL-backed access* than turnkey host takeover, the product is a niche line-of-business platform rather than ubiquitous edge software, and there is no KEV listing or public exploitation evidence in accessible indexed sources. That keeps this firmly important, but it does not read like a universal emergency patch event for every enterprise on Monday morning.
4 steps from start to impact.
Find an exposed Akmer/TeknoPass web surface
Akmer or TeknoPass branding. Tools like httpx, nmap, or even basic search-engine indexing are enough because this is an application-layer issue, not a memory-corruption chain.- A web-facing Akmer/TeknoPass portal or API must be reachable from the attacker's network position
- The vulnerable endpoint must be exposed in that portal
- Many parking and gate-control deployments sit on internal networks, site-to-site VPNs, or vendor-managed access paths rather than open internet exposure
- Branding may be removed or hidden behind reverse proxies, slowing mass identification
Tamper with the record identifier using Burp Repeater or sqlmap
Burp Repeater; sqlmap may help if the backend also mishandles SQL construction, but the title suggests the core weakness is authorization tied to attacker-chosen row identifiers rather than pure free-form SQL syntax injection.- A user-controlled identifier is accepted by the endpoint
- The application fails to bind access decisions to the authenticated or intended object owner
- Endpoints may require some workflow knowledge, valid object IDs, or predictable numbering
- Randomized UUIDs and tenant scoping raise attacker effort even when authorization checks are flawed
Read or overwrite unauthorized rows
- Backend queries must dereference the attacker-supplied key without enforcing ownership or tenant checks
- The target rows must contain sensitive or operationally meaningful data
- Blast radius may stay within one site, one tenant, or one application database rather than extending to host-level code execution
- Read/write scope depends heavily on which tables the vulnerable endpoint touches
Turn data access into business disruption
- The compromised records must influence live parking, payment, or access-control decisions
- Operational monitoring must fail to quickly catch inconsistent records
- Many deployments have attendants, camera review, barrier logs, and reconciliation processes that limit silent long-term abuse
- Business impact can be severe locally without becoming enterprise-wide catastrophic compromise
The supporting signals.
| In-the-wild status | No confirmed public exploitation evidence found in accessible indexed sources at assessment time. |
|---|---|
| KEV status | Not listed in CISA KEV as of this assessment. |
| PoC availability | No public PoC located in accessible indexed sources. Expect exploit development to be straightforward once endpoint details are known because this class is usually testable with Burp Repeater and sometimes sqlmap. |
| EPSS | Not confirmed from accessible indexed sources during this assessment; absence of public exploitation and niche product footprint are the bigger signals here than any model score. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — this is the vendor's worst-case internet-exposed, no-auth interpretation, not a deployment-aware severity. |
| CWE interpretation | The title maps more naturally to CWE-566 than generic CWE-89. That matters because a row-level authorization flaw is usually less wormable than broad arbitrary SQL execution. |
| Affected versions | Publicly unclear. Indexed sources available at assessment time do not clearly enumerate build ranges; treat deployed Akmer/TeknoPass web software as suspect until vendor version guidance is published. |
| Fixed version | Unknown in publicly indexed sources at assessment time; no authoritative patched build string was located. |
| Exposure reality | Akmer/TeknoPass appears to be a niche parking and access-control platform, not broadly deployed internet edge software. That sharply reduces reachable population versus what a 9.8 score implies. |
| Scanner / exposure data | No trustworthy Shodan/Censys/FOFA exposure count located in accessible indexed sources for this product name; assume exposure is environment-specific and verify with your ASM inventory instead of internet-wide guesses. |
noisgate verdict.
The decisive downgrade factor is reachable population: this looks like a niche line-of-business parking/access platform whose vulnerable workflows are far less exposed in real enterprises than the vendor's internet-maximal 9.8 suggests. It still lands in HIGH because the bug is reportedly unauthenticated, remotely reachable at the application layer, and can plausibly alter sensitive operational records if the portal is exposed.
Why this verdict
- Down from 9.8 because deployment reality matters: Akmer/TeknoPass is a niche parking/access-control application, not a universally exposed edge stack, so the reachable population is materially smaller than the vendor CVSS assumes.
- Down again because the title suggests row-level auth failure, not guaranteed host takeover:
CWE-566usually means unauthorized object access or modification through attacker-chosen keys, which is serious but often narrower than full arbitrary SQL execution or RCE. - No active-exploitation amplifier: no KEV listing, no public campaign evidence, and no public PoC found in accessible indexed sources, so there is no reason to keep it in the emergency
drop everythingbucket.
Why not higher?
I am not keeping this at CRITICAL because the available facts do not show widespread internet exposure, public exploitation, or a reliable path from the application flaw to immediate host-level compromise. The vendor's 9.8 is technically plausible only in the most exposed configuration and ignores how rarely this kind of product is deployed as a broad anonymous internet surface.
Why not lower?
I am not pushing it to MEDIUM because the reported path is still remote, no-auth, low-complexity at the web layer and the affected product appears tied to physical access and payment operations. If your portal is reachable, unauthorized reads and writes against operational records can absolutely create real business impact.
What to do — in priority order.
- Put the portal behind an access broker — Require VPN, ZTNA, or an identity-aware proxy for any Akmer/TeknoPass web interface not strictly needed on the public internet. For a HIGH verdict, deploy this within 30 days if patching cannot be completed first, because the biggest risk reducer here is shrinking anonymous reachability.
- Constrain source IPs — Restrict management, kiosk-admin, and API access to known site networks, vendor support ranges, and administrator jump hosts. Apply within 30 days; this directly attacks the unauthenticated remote prerequisite.
- Turn on database and application auditing — Log object-ID access, update operations, bulk sequential record requests, and admin/API mutations on parking sessions, plate mappings, balances, and access-control tables. Enable within 30 days so you can detect row-walking and unauthorized record changes that perimeter controls may miss.
- Review app roles and tenant scoping — Even if the bug is pre-auth in some paths, many real deployments expose adjacent authenticated workflows with excessive read/write scope. Tighten site, tenant, and operator permissions within 30 days to reduce blast radius if exploitation lands inside partially trusted workflows.
- Monitor for IDOR-style probing — Create detections for rapid increments across numeric IDs, repeated 200 responses on neighboring object identifiers, unusual access to historical sessions, and mismatches between gate events and billing records. Stand this up within 30 days because this weakness often looks like valid business traffic unless you watch for enumeration patterns.
- A generic WAF-only stance does not solve this well; attacker input may be a perfectly normal-looking integer or UUID, not a classic
' OR 1=1payload. - Simply hiding the login page or changing URLs is weak protection; once the object endpoint is found, the flaw is in authorization logic, not obscurity.
- Anti-virus/EDR on the server is not your primary control here; if the attacker only reads or changes rows through the app, endpoint tooling may see nothing obviously malicious.
Crowdsourced verification payload.
Run this from an auditor workstation that can reach the target web application, not from the database server. Invoke it as python3 check_cve_2026_4104.py https://parking.example.com or python3 check_cve_2026_4104.py https://parking.example.com --fixed-version 2026.06.15; no admin privileges are required, only outbound HTTPS access to the target.
#!/usr/bin/env python3
# check_cve_2026_4104.py
# Purpose: lightweight external fingerprint for Akmer/TeknoPass exposure and visible versioning.
# This does NOT exploit the target. It reports VULNERABLE / PATCHED / UNKNOWN based on visible product markers
# and optionally a defender-supplied fixed version string.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/network error
import argparse
import re
import sys
from urllib.parse import urljoin
try:
import requests
except Exception:
print('UNKNOWN - missing dependency: requests')
sys.exit(2)
PRODUCT_MARKERS = [
r'Akmer',
r'Akmer\s*Bili',
r'TeknoPass',
r'otopark',
r'access\s*control',
r'parking\s*automation',
]
VERSION_PATTERNS = [
r'version\s*[:=]\s*([0-9][0-9A-Za-z._\-]+)',
r'build\s*[:=]\s*([0-9][0-9A-Za-z._\-]+)',
r'v([0-9]+(?:\.[0-9A-Za-z_\-]+)+)',
]
COMMON_PATHS = [
'/',
'/login',
'/admin',
'/api',
'/swagger',
'/docs',
]
def normalize(v):
return re.sub(r'[^0-9A-Za-z]+', '.', v).strip('.').lower()
def looks_like_product(text):
for pat in PRODUCT_MARKERS:
if re.search(pat, text, re.IGNORECASE):
return True
return False
def extract_version(text):
for pat in VERSION_PATTERNS:
m = re.search(pat, text, re.IGNORECASE)
if m:
return m.group(1)
return None
def fetch(session, base, path):
url = urljoin(base.rstrip('/') + '/', path.lstrip('/'))
try:
r = session.get(url, timeout=10, allow_redirects=True, verify=True)
return url, r.status_code, r.text[:500000]
except requests.RequestException:
return url, None, ''
def main():
ap = argparse.ArgumentParser(description='Non-intrusive Akmer/TeknoPass exposure/version check for CVE-2026-4104')
ap.add_argument('base_url', help='Base URL, e.g. https://parking.example.com')
ap.add_argument('--fixed-version', help='Known fixed version/build from vendor advisory, if available')
args = ap.parse_args()
session = requests.Session()
session.headers.update({'User-Agent': 'noisgate-cve-2026-4104-check/1.0'})
product_seen = False
discovered_version = None
reachable = False
seen_urls = []
for path in COMMON_PATHS:
url, status, text = fetch(session, args.base_url, path)
seen_urls.append((url, status))
if status is not None:
reachable = True
if not text:
continue
if looks_like_product(text):
product_seen = True
if discovered_version is None:
discovered_version = extract_version(text)
if not reachable:
print('UNKNOWN - target not reachable from this workstation')
sys.exit(3)
if not product_seen:
print('UNKNOWN - no visible Akmer/TeknoPass markers detected on common paths')
sys.exit(2)
if args.fixed_version and discovered_version:
if normalize(discovered_version) == normalize(args.fixed_version):
print(f'PATCHED - product marker found and visible version/build matches supplied fixed version: {discovered_version}')
sys.exit(0)
else:
print(f'VULNERABLE - product marker found and visible version/build ({discovered_version}) does not match supplied fixed version ({args.fixed_version})')
sys.exit(1)
if discovered_version and not args.fixed_version:
print(f'UNKNOWN - Akmer/TeknoPass marker found; visible version/build discovered: {discovered_version}; compare manually to vendor fixed build once published')
sys.exit(2)
print('UNKNOWN - Akmer/TeknoPass marker found but no trustworthy version/build string exposed; use authenticated inventory or vendor advisory to confirm patch state')
sys.exit(2)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.