CVE-2023-42241

Executive Summary

CVE-2023-42241 is an authenticated SQL injection vulnerability in Selesta Visual Access Manager (VAM), a web-based access-management console, affecting all versions prior to 4.42.2. An authenticated attacker — including a low-privileged operator account — can inject arbitrary SQL through multiple POST parameters of the /vam/vam_anagraphic.php endpoint, enabling database exfiltration, record tampering, and potential privilege escalation within the VAM platform. No CVSS score or vector has been published, no public PoC or exploit code is known, the CVE is not listed in CISA KEV, and no patch source has been confirmed by tracked intelligence channels; the current EPSS probability of in-the-wild exploitation is low (0.00241, 15.6th percentile).

Technical Analysis

The vulnerability exists in the web application component of Selesta Visual Access Manager (VAM), specifically in the anagraphic (records/registry) management page exposed at /vam/vam_anagraphic.php. The NVD description states that "an authenticated attacker can perform SQL Injection in multiple POST parameters" of this endpoint, and that affected versions are prior to 4.42.2. The source record lists CWE as N/A and does not provide a CVSS vector; however, the vulnerability class is unambiguous from the description: classic SQL injection, mapped to CWE-89.

Attack mechanism: the application likely constructs SQL queries by concatenating attacker-controlled values received via HTTP POST without parameterized queries or adequate input sanitization/escaping. The phrase "multiple POST parameters" indicates the flaw is not confined to a single field — several inputs processed by the same handler are vulnerable, expanding the reachable attack surface for any authenticated user. Because the injection is delivered in the HTTP request body, it is largely invisible to standard web-server access logs that record only request metadata (method, URI, status), which shifts detection burden onto reverse proxies, WAFs, and IDS/IPS sensors with body inspection capability.

Affected product context: Visual Access Manager is a management console for physical/visual access-control environments. The "anagraphic" module processes personnel/registry data and access-right assignments, meaning the backing database very likely contains sensitive personal data (employees, contractors, visitors) and authentication material for VAM operator accounts. The authentication requirement reduces the externally exposed attack surface compared to unauthenticated SQLi, but it elevates the relative severity of insider threats and credential-compromise scenarios: a single valid but low-privileged VAM account becomes a functional foothold for structured query injection.

Boundary conditions and intelligence gaps: the precise vulnerable parameter names are not disclosed in the NVD description; the underlying DBMS, the query grammar, and the exact application code path are also unpublished. Insufficient technical detail is available to enumerate specific payload syntax that will succeed against a given backend, so both exploitation guidance and detection logic must operate at the vulnerability-class level. No exploit code, Nuclei template, or PoC has been observed, and the CISA KEV catalog does not list this CVE.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred strictly from the vulnerability class and the NVD description.

1. Reconnaissance / target identification: An attacker first identifies VAM instances via internet scans or Shodan-style queries for "Visual Access Manager", "VAM", or the /vam/vam_anagraphic.php path in HTML titles and page content. Because the vulnerability requires authentication, the attacker must also obtain valid credentials — via credential stuffing against the VAM login page, harvesting from prior breaches, default/shared operator accounts common in physical-security deployments, or an insider with legitimate access. In many OT-adjacent access-control environments, weak operator credentials are the primary barrier, and this CVE transforms any such compromise into full database access.

2. Triggering the flaw: Once authenticated, the attacker sends HTTP POST requests directly to /vam/vam_anagraphic.php. The vulnerable handler processes multiple POST parameters in the anagraphic (registry) workflow. The attacker begins by submitting a single quote (') in candidate parameters to induce a SQL syntax error, then iteratively tunes payloads to confirm which parameters are injectable, how the query responds (in-band vs. blind), and what database backend is in use. Since parameter names are not publicly disclosed, field enumeration is a manual or scripted part of this step.

3. Payload/execution method (class-level): The attacker embeds SQLi payloads in the POST body using techniques matched to the backend: boolean-based blind conditions (e.g., ' OR '1'='1, AND 1=1) to alter query truth values; UNION-based SELECT stacking to return attacker-chosen data inside the application's rendered response; time-based blind functions (e.g., SLEEP(), WAITFOR DELAY, BENCHMARK()) where responses are indistinguishable; and stacked/batched queries where the backend and DBMS session privileges permit them. These classes of payloads are used to enumerate the database schema, dump table contents, and probe for write or command-execution capabilities.

4. Post-exploitation impact: Successful SQL injection against vam_anagraphic.php yields both read and likely write access to the VAM database. Concrete outcomes include: exfiltration of personnel/visitor PII from the anagraphic registry; retrieval of VAM operator credential hashes enabling administrator account takeover; silent modification of access-rights records, granting unauthorized physical-access privileges to facilities; and, on some DBMS configurations with elevated privileges, OS-level command execution via extended stored procedures or file-write primitives. Because the compromised application governs access-control decisions, the blast radius extends from the database to the physical security posture of the affected organization.

Impact Assessment

No CVSS score or vector has been published for CVE-2023-42241 (the NVD record shows "N/A" for both), so no quantitative severity subscores are available; the following qualitative assessment applies.

Business impact: VAM is operational-technology adjacent — it manages physical/visual access control. A compromised VAM database exposes PII of employees, contractors, and visitors, potentially triggering regulatory notification obligations (e.g., GDPR). Integrity impact may be more severe than confidentiality: modification of anagraphic and access-right records can result in unauthorized individuals being granted physical access to facilities, directly undermining the security function the product exists to provide. Availability impact is possible if the injection surface permits destructive SQL (e.g., DROP/TRUNCATE) or administrative lockout.

Blast radius: the immediate blast radius covers the VAM application server, its backend database, and the access-control records it manages. If credential material recovered from the database is reused across enterprise systems (common in legacy physical-security deployments), the blast radius expands into the broader identity environment. All organizations running Selesta VAM below version 4.42.2 are affected — and given patch confidence of 0/4 with no confirmed patch source, this population currently has no verified remediation path.

Exploitation-likelihood context: CISA KEV does not list CVE-2023-42241, no exploit code or PoC has been observed, and EPSS estimates in-the-wild exploitation probability at 0.00241 (15.6th percentile of exploited CVEs). These signals suggest active exploitation is not currently widespread, providing defenders a window to apply the mitigations below before weaponization becomes public.

Detection Guidance

The rules below target the only concrete, verifiable artifact in the NVD description: HTTP POST requests to the /vam/vam_anagraphic.php path whose request bodies contain SQL injection markers. Because the exact vulnerable parameter names are unpublished, detection matches on the endpoint plus generic SQLi syntax. Where POST-body logging does not exist in standard access logs, enable body logging at the reverse proxy, WAF, or load balancer fronting the VAM console; otherwise the payloads will be invisible to log-based detection.

Sigma Rule

title: Selesta Visual Access Manager SQL Injection Attempt (CVE-2023-42241)
id: 9f1c7a2b-5d3e-4a8b-9c0d-2e4f6a8b0c1d
status: experimental
description: Detects POST requests to /vam/vam_anagraphic.php containing SQL injection patterns in the request body. Requires HTTP body logging from a proxy, WAF, or load balancer.
date: 2024/03/01
author: Valtersit Threat Intelligence
logsource:
  category: webserver
  product: generic
detection:
  selection_endpoint:
    http.method: POST
    http.uri|contains: "/vam/vam_anagraphic.php"
  selection_sqli:
    http.request.body|contains:
      - "' OR"
      - "OR 1=1"
      - "AND 1=1"
      - "UNION SELECT"
      - "UNION ALL SELECT"
      - "SLEEP("
      - "WAITFOR DELAY"
      - "BENCHMARK("
      - "';--"
      - "/*"
  condition: selection_endpoint and selection_sqli
falsepositives:
  - Unlikely in normal operator traffic; SQL keywords in POST bodies to this endpoint merit investigation
level: high
tags:
  - attack.t1190
  - cwe.89
  - cve.2023-42241

YARA Rule

/*
   YARA rule for CVE-2023-42241 — Selesta Visual Access Manager SQL Injection.
   Scan captured HTTP traffic (PCAP exports, proxy logs, or WAF request archives)
   for requests targeting the vulnerable endpoint with SQLi markers.
*/
rule CVE_2023_42241_Selesta_VAM_SQLi
{
    meta:
        author      = "Valtersit Threat Intelligence"
        description = "Detects SQL injection payloads aimed at /vam/vam_anagraphic.php (Selesta VAM < 4.42.2)"
        cve         = "2023-42241"
        date        = "2024-03-01"
        severity    = "high"
        reference   = "https://nvd.nist.gov/vuln/detail/CVE-2023-42241"

    strings:
        $endpoint = "/vam/vam_anagraphic.php" ascii wide nocase
        $sqli_union  = /UNION[[:space:]]+(ALL[[:space:]]+)?SELECT/ ascii nocase
        $sqli_bool   = /(OR|AND)[[:space:]]+1=1/ ascii nocase
        $sqli_quote  = "' OR" ascii wide nocase
        $sqli_sleep  = /SLEEP[[:space:]]*\(/ ascii nocase
        $sqli_delay  = /WAITFOR[[:space:]]+DELAY/ ascii nocase
        $sqli_bench  = /BENCHMARK[[:space:]]*\(/ ascii nocase
        $sqli_comment = /'--|'#/ ascii nocase

    condition:
        (
            uint16(0) == 0x0A0D or
            uint16(0) == 0x0D0A or
            filesize < 100MB
        )
        and $endpoint
        and 2 of ($sqli_*)
}

Suricata IDS Rule

alert http $EXTERNAL_NET any -> $HOME_NET any ( \
  msg:"CVE-2023-42241 Selesta Visual Access Manager vam_anagraphic.php SQL injection attempt"; \
  flow:established,to_server; \
  content:"POST"; http.method; \
  content:"/vam/vam_anagraphic.php"; http.uri; \
  pcre:"/(\x27[[:space:]]*(OR|AND)|UNION[[:space:]]+(ALL[[:space:]]+)?SELECT|(OR|AND)[[:space:]]+1=1|SLEEP[[:space:]]*\(|WAITFOR[[:space:]]+DELAY|BENCHMARK[[:space:]]*\()/i"; \
  http.request_body; \
  sid:29004223; rev:1; \
  metadata:cve 2023-42241, mitre_attack_id T1190;)

Deployment note: place this signature on the IDS/IPS positioned in front of the Selesta VAM console and ensure TLS inspection is enabled so the sensor sees clear-text request bodies. If the console is reachable only from trusted operator segments, adjust $HOME_NET/$EXTERNAL_NET accordingly.

Elastic Detection

EQL rule (Elastic Security SIEM, ECS field names assumed):

any where
  event.category == "web" and
  http.request.method == "POST" and
  url.path == "/vam/vam_anagraphic.php" and
  (
    http.request.body.content like~ "*' or*" or
    http.request.body.content like~ "*' and *" or
    http.request.body.content like~ "*union select*" or
    http.request.body.content like~ "*or 1=1*" or
    http.request.body.content like~ "*and 1=1*" or
    http.request.body.content like~ "*sleep(*" or
    http.request.body.content like~ "*waitfor delay*" or
    http.request.body.content like~ "*benchmark(*"
  )

If the environment logs HTTP metadata only (no request bodies), replace the body conditions with a lower-confidence baseline: url.path == "/vam/vam_anagraphic.php" and http.request.method == "POST" — treat such matches as candidates for manual review rather than confirmed detections.

Splunk SPL Query

index=web sourcetype=access_combined
| where method="POST" AND uri_path="/vam/vam_anagraphic.php"
| regex _raw="(?i)(\x27[[:space:]]*(OR|AND)|UNION[[:space:]]+(ALL[[:space:]]+)?SELECT|(OR|AND)[[:space:]]+1=1|SLEEP[[:space:]]*\(|WAITFOR[[:space:]]+DELAY|BENCHMARK[[:space:]]*\()"
| eval cve="CVE-2023-42241", alert="Selesta_VAM_SQLi_Attempt"
| stats count earliest(_time) latest(_time) by src_ip, dest_ip, dest_port, uri_path, method, cve, alert

Note: access_combined logs typically omit POST bodies. If your pipeline ingests proxy or WAF logs that capture request bodies (e.g., Pan-OS traffic logs, custom JSON body fields), run the same regex against the body field (e.g., form_data or http_request_body) instead of _raw. Alert on any match from a non-operator source IP.

Wazuh OSSEC Rule

Add to /var/ossec/etc/rules/local_rules.xml (custom rule IDs above 100000):

<group name="web,sql_injection,">
  <rule id="100423" level="10">
    <decoded_as>web</decoded_as>
    <field name="url">/vam/vam_anagraphic\.php</field>
    <field name="method">POST</field>
    <regex>('([[:space:]]+OR|[[:space:]]+AND|--|#)|UNION[[:space:]]+(ALL[[:space:]]+)?SELECT|(OR|AND)[[:space:]]+1=1|SLEEP[[:space:]]*\(|WAITFOR[[:space:]]+DELAY|BENCHMARK[[:space:]]*\()</regex>
    <description>Selesta Visual Access Manager (CVE-2023-42241): SQL injection attempt against vam_anagraphic.php</description>
    <mitre>
      <id>1190</id>
    </mitre>
    <group>attack,exploitation_public_facing_application,</group>
  </rule>
</group>

Validate the decoder field names (url, method) against your local Apache/nginx log format and Wazuh decoder (decoded_as: web) before production deployment; if method is not populated by the decoder, remove that field check and rely on the URI plus regex match.

Mitigation & Patch Guidance

Patch confidence for CVE-2023-42241 is 0/4 — no patch evidence from any tracked source, and the patch-sources list is empty. The NVD description implies VAM 4.42.2 is the fixed release ("prior to 4.42.2"), but no vendor advisory, changelog, or download link has been confirmed. Until a verified patch is available, treat all VAM deployments as vulnerable.

1. Immediate mitigations:

• Restrict network access to the VAM console: place /vam/ behind a VPN or source-IP allowlist and block direct internet exposure of vam_anagraphic.php at the perimeter firewall.
• Deploy a WAF (e.g., ModSecurity with OWASP CRS, or a cloud WAF) in front of VAM with SQL injection rulesets enabled; where inline blocking is acceptable, use the Suricata rule above on an IPS.
• Enforce strong authentication: disable default and shared accounts, force MFA for all VAM operator accounts, and promptly revoke credentials for terminated employees and third parties.
• Enable request-body logging at the reverse proxy/WAF layer so exploitation attempts are visible to the SIEM (see Detection Guidance).
• Audit current VAM accounts for anomalies and review recent access history to vam_anagraphic.php.

2. Patch/upgrade steps:

• Contact Selesta directly to confirm the availability of VAM 4.42.2 (or later) and request the official advisory for CVE-2023-42241; no tracked source currently confirms the patch, so do not assume 4.42.2 is downloadable without vendor verification.
• Plan the upgrade in a maintenance window: back up the VAM database and configuration, validate the upgrade in a staging instance mirroring production, then deploy to production.
• After upgrade, re-run the detection queries to confirm no residual exploitation traffic and verify that the SQLi behavior is remediated.

3. Long-term hardening:

• Require the vendor to confirm that all queries in vam_anagraphic.php and the wider application use parameterized prepared statements; if VAM is a legacy product, obtain a deprecation/roadmap commitment.
• Segment the VAM network from general corporate IT and from physical access-control controllers; isolate the database tier and firewall it from the application tier.
• Integrate VAM authentication with the enterprise identity provider to eliminate local/default credentials, and conduct regular credential audits.
• Monitor vendor release channels and CISA advisories for this CVE; subscribe to EPSS feeds to track any rise in exploitation probability above the current 0.00241 baseline.

References

Public detail for this CVE is sparse; the following are the primary authoritative tracking sources. No vendor advisory, researcher blog, or exploit write-up has been identified to date, and no CISA KEV entry applies.

• NVD — CVE-2023-42241: https://nvd.nist.gov/vuln/detail/CVE-2023-42241
• MITRE CVE Record — CVE-2023-42241: https://www.cve.org/CVERecord?id=CVE-2023-42241
• FIRST EPSS — CVE-2023-42241: https://www.first.org/epss/search?cve=CVE-2023-42241
• CISA Known Exploited Vulnerabilities Catalog (CVE NOT listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Vendor advisory: none identified among tracked sources as of the report date (patch confidence 0/4). Organizations should contact Selesta directly and request the release notes for VAM 4.42.2.

Threat-actor campaign notes: No campaigns, exploit-in-the-wild evidence, or public PoC have been observed for CVE-2023-42241 as of this report. EPSS (0.00241, 15.6th percentile) and the CISA KEV absence support a low current exploitation likelihood; however, the vulnerability affects an access-control product containing attractive physical-security and personnel data, so the overall risk profile is driven primarily by the exposure of the VAM console and the strength of its authentication barrier.