← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-4104 · CWE-89 · Disclosed 2026-06-04

Authorization bypass through User-Controlled SQL primary key vulnerability in Akmer Informatics Automation…

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"Bad bug, wrong bucket: serious if exposed, but not a universal drop-everything 9.8"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find an exposed Akmer/TeknoPass web surface

The attacker first identifies a reachable parking or access-control web interface, typically by using normal browser recon or search tooling and fingerprinting for 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.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: External attack-surface tools can find the host, but version scanners will be weak here because public fixed-version metadata is not clearly published.
STEP 02

Tamper with the record identifier using Burp Repeater or sqlmap

The attacker modifies a numeric or tokenized primary-key-style parameter such as a ticket ID, plate mapping ID, user ID, session ID, or transaction ID. In practice this is often trivial with 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.
Conditions required:
  • A user-controlled identifier is accepted by the endpoint
  • The application fails to bind access decisions to the authenticated or intended object owner
Where this breaks in practice:
  • 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
Detection/coverage: DAST can sometimes catch this if business-logic coverage is deep; generic SAST or WAF signatures often miss it because the payload can look like a valid integer.
STEP 03

Read or overwrite unauthorized rows

Once the backend trusts the supplied primary key, the attacker can pull back records belonging to other users or mutate operational data outside their scope. That can include parking sessions, vehicle allowlists, balances, receipts, access events, or identity mappings depending on where the vulnerable handler sits.
Conditions required:
  • Backend queries must dereference the attacker-supplied key without enforcing ownership or tenant checks
  • The target rows must contain sensitive or operationally meaningful data
Where this breaks in practice:
  • 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
Detection/coverage: Look for sequential object-ID access patterns, anomalous 200 responses across many IDs, and spikes in API reads/updates against object endpoints from a single source.
STEP 04

Turn data access into business disruption

The practical impact is operational tampering rather than glamorous shell access: altered plate mappings, forged parking exits, manipulated kiosk/accounting records, or corrupted gate-control history can disrupt physical access and revenue workflows. If the vulnerable workflow touches configuration or entitlement tables, the attacker may also create durable unauthorized access paths inside the application.
Conditions required:
  • The compromised records must influence live parking, payment, or access-control decisions
  • Operational monitoring must fail to quickly catch inconsistent records
Where this breaks in practice:
  • 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
Detection/coverage: Correlate application logs, LPR/turnstile events, and billing anomalies; database audit trails are more useful than perimeter IDS for this class.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed public exploitation evidence found in accessible indexed sources at assessment time.
KEV statusNot listed in CISA KEV as of this assessment.
PoC availabilityNo 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.
EPSSNot 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 vectorCVSS: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 interpretationThe 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 versionsPublicly 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 versionUnknown in publicly indexed sources at assessment time; no authoritative patched build string was located.
Exposure realityAkmer/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 dataNo 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.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to HIGH (7.4/10)

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.

MEDIUM Severity reassessment versus vendor 9.8 baseline
LOW Exact affected and fixed version precision
MEDIUM Operational impact model for parking/access-control workflows

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-566 usually 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 everything bucket.

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
What doesn't work
  • 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=1 payload.
  • 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.
06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat exposed Akmer/TeknoPass portals as a HIGH application-risk item: identify every reachable instance, put public-facing ones behind VPN/ZTNA or IP allowlists, and turn on audit logging for object-ID access and record changes. Per the noisgate mitigation SLA, apply those exposure-reduction controls within 30 days if patching is not already done; per the noisgate remediation SLA, get the actual vendor-fixed build rolled out within 180 days once Akmer publishes authoritative version guidance. If you discover one of these portals is openly reachable from the internet today, do not wait for the long patch window before reducing exposure.

Sources

  1. Akmer Bilişim company site
  2. Akmer Bilişim English product/company overview
  3. TeknoPass product site
  4. TeknoPass English overview
  5. MITRE CWE-566
  6. MITRE CWE-89
  7. CISA Known Exploited Vulnerabilities Catalog
  8. FIRST CVSS v3.1 Specification
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.