☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
[ VENDOR STATS ]
SOON 🐛 CWE-284
👁️
Common Weakness Enumeration - Identifies the specific category of software weakness or flaw.

CVE-2024-34320

CVE-2024-34320 Improper Access Control in ProPhoenix
📅 PUBLISHED: 2026-10-13 00:00 UTC
⏳ SCORE PENDING — ANALYSIS IN PROGRESS [ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🥷 MITRE: T1190
👁️
MITRE ATT&CK Tactic - Describes the strategy hackers use to execute this attack.
VULNERABLE: 2022.2403.3.101
CVSS SEVERITY SCALE
9.0–10.0 CRITICAL
7.0–8.9 HIGH
4.0–6.9 MEDIUM
0.1–3.9 LOW
0.0 NONE
SOON
PENDING NVD
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2024-34320 is an incorrect access control vulnerability affecting ProPhoenix Law RMS version 2022.2403.3.101, a records-management platform used by law-enforcement and public-safety agencies. The flaw resides in sensitive API endpoints that fail to properly enforce authorization, allowing an attacker to reach functionality or data that should require elevated privileges. Because access control is broken in endpoints explicitly described as sensitive, successful exploitation can expose or manipulate law-enforcement records data, with high confidentiality and integrity impact.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Technical Analysis

The NVD description states that ProPhoenix Law RMS v2022.2403.3.101 "was discovered to contain an incorrect access control issue in sensitive API endpoints." This places the vulnerability squarely in the broken access control family (CWE-284, Improper Access Control), specifically a case where an API endpoint does not correctly verify that the requester holds the authority required for the requested operation.

The exact defect class within that family — for example, missing function-level authorization, insecure direct object reference, or privilege-scope confusion — cannot be determined from the available description. No endpoint paths, HTTP methods, parameter names, or authentication mechanisms are disclosed in the CNA title or NVD description. Accordingly, this analysis confines itself to the vulnerability class and does not assert specific implementation details.

Key characteristics derivable from the provided data:

  • Attack surface: network-reachable API endpoints. Per the CVSS vector (AV:N), the vulnerable component is exploitable remotely over the network.
  • Authentication/authorization gap: the "incorrect access control" language indicates the endpoint's authorization check is either absent, bypassable, or applied at the wrong privilege tier. The attacker is not required to possess the legitimate elevated role the endpoint is meant to gate.
  • Sensitivity: the endpoints are described as "sensitive," implying they expose or mutate data whose handling is regulated (records management / law-enforcement context). This drives the high confidentiality and integrity ratings.
  • No user interaction or special conditions: the vector specifies UI:N and AC:L, indicating straightforward remote exploitation for an attacker who can reach the endpoint.

Because authorization logic is the broken control, traditional perimeter defenses (TLS, network segmentation to trusted clients) do not mitigate the flaw — a legitimate-looking but under-privileged or unauthenticated request can be accepted as authorized. This is the defining risk of broken access control: the application itself makes the wrong trust decision.

No public proof-of-concept, Nuclei template, or exploit code is known. The attack chain discussed below is therefore inferred from the vulnerability class rather than from a published exploit. No CWE was officially assigned in the provided data; CWE-284 is used here as the closest match to "incorrect access control."

Exploitation Scenarios

The following describes the exploit chain at the vulnerability-class level. No specific endpoints, parameters, or payloads are named because none are provided in the source data; inventing them would be inaccurate.

  1. Reconnaissance / target identification. An adversary identifies internet- or network-exposed ProPhoenix Law RMS instances, for example through search-engine and internet-scanning services, or through exposed service banners. Because the product is deployed by law-enforcement and public-safety organizations, targets are typically reachable via a web/API tier (port 443/80 or a management interface). The attacker maps the API surface of the exposed instance.

  2. Trigger of the specific flaw class. The attacker sends requests to the sensitive API endpoints. Because the access-control check is incorrect, the request is either not properly authenticated or not properly authorized at the required privilege level. The exact trigger (whether a missing authorization check, a role check that can be satisfied by a lower-privileged identity, or an object reference that escapes scope) is not disclosed. In all cases, the application makes a faulty authorization decision and processes the request as though the caller were entitled to it.

  3. Payload / execution method. At the vulnerability-class level, exploitation consists of issuing otherwise-legitimate API calls that the attacker should not be permitted to make. No code execution, memory corruption, or injection is implied by the description; the "payload" is simply a request that the broken access-control logic accepts. There is no public PoC, and the exact request format cannot be stated without fabrication.

  4. Post-exploitation impact. Depending on what the sensitive endpoints expose or allow, the attacker gains unauthorized read and/or write access to records-management data. Given the CVSS vector's high confidentiality and high integrity scores, the realistic outcomes are mass disclosure of sensitive case/records data and unauthorized modification or deletion of records. Integrity impact of this kind is especially serious in a law-enforcement records context, where data authenticity is legally significant.

No evidence of exploitation in the wild, threat-actor attribution, or CISA KEV listing is associated with this CVE in the provided data.

Impact Assessment

The CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H describes the impact profile derived from the vulnerability class:

  • Confidentiality: High — sensitive records-management data reachable through the mis-authorized endpoints can be read. In a Law RMS context this may include personally identifiable information, case records, and other regulated data.
  • Integrity: High — the same broken control permits unauthorized modification if the endpoints allow write operations.
  • Availability: High per the vector, reflecting the potential for disruptive operations against records data.
  • Scope: Unchanged — the vulnerable component and impacted component are the same (S:U).
  • Exploitability: Network-reachable, low complexity, no privileges and no user interaction required — the most favorable conditions for an attacker.

Business impact includes regulatory and legal exposure (data-protection obligations for law-enforcement data), reputational harm to the operating agency, potential invalidation of records whose integrity is questioned, and downstream risk to investigations and prosecutions that depend on those records. Blast radius depends on how broadly the sensitive endpoints are exposed: an internet-facing instance exposes the full records surface to any remote attacker able to locate it.

Detection Guidance

Detection should focus on anomalous access to records-management API endpoints — requests from unexpected source contexts, role/authorization mismatches, high-volume enumeration, and reads/writes inconsistent with the caller's normal profile. The rules below are generic because no specific endpoint paths are published; tune them to the actual API paths and authentication logs of the deployed instance.

Sigma Rule

title: Suspicious Access to ProPhoenix Law RMS Sensitive API Endpoints
id: 8b2f1c74-3a9e-4d21-b6c0-1f9e7d5a2c33
status: experimental
description: Detects anomalous or unauthorized access patterns against Law RMS sensitive API endpoints indicative of broken access control abuse (CVE-2024-34320)
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2024-34320
author: valtersit.com
date: 2024/05/01
logsource:
  category: webserver
  product: generic
detection:
  selection_method:
    cs-method:
      - GET
      - POST
      - PUT
      - DELETE
      - PATCH
  selection_api:
    cs-uri-stem|contains:
      - '/api/'
  selection_sensitive:
    cs-uri-stem|contains:
      - 'records'
      - 'case'
      - 'lawrms'
      - 'admin'
  filter_authorized:
    sc-status:
      - 200
      - 201
  condition: selection_method and selection_api and selection_sensitive and filter_authorized
falsepositives:
  - Legitimate authorized administrative access
  - Authorized bulk data export operations
level: high
tags:
  - attack.t1190
  - cve.2024.34320

YARA Rule

rule CVE_2024_34320_ProPhoenix_LawRMS_Access_Control
{
    meta:
        description = "Detects references to ProPhoenix Law RMS sensitive API access indicative of CVE-2024-34320 probing"
        author = "valtersit.com"
        date = "2024-05-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-34320"
        cve = "CVE-2024-34320"

    strings:
        $prod1 = "ProPhoenix" ascii nocase
        $prod2 = "Law RMS" ascii nocase
        $prod3 = "LawRMS" ascii nocase
        $api   = "/api/" ascii nocase
        $rec1  = "records" ascii nocase
        $rec2  = "case" ascii nocase
        $rec3  = "sensitive" ascii nocase

    condition:
        (any of ($prod*)) and $api and (any of ($rec*))
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2024-34320 ProPhoenix Law RMS Suspicious Sensitive API Access"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"/api/"; http.uri; nocase; content:"records"; http.uri; nocase; content:"records"; http.uri; nocase; content:"case"; http.uri; nocase; http.header; content:"ProPhoenix"; nocase; threshold:type both, track by_src, count 20, seconds 60; reference:cve,2024-34320; classtype:attempted-recon; sid:202434320; rev:1;)

Note: the http.uri content clauses are redundant in a strict engine and should be trimmed to the single best-matching path keyword for the deployed instance. Tune to observed API paths.

Elastic Detection

sequence by source.ip with maxspan=5m
  [ network where network.protocol == "http" and url.path : "/api/*" and http.request.method in ("GET","POST","PUT","DELETE","PATCH") and url.path : ("*records*","*case*","*admin*") and http.response.status_code == 200 ]

This EQL sequence highlights repeated successful requests to sensitive API paths, which is characteristic of access-control abuse enumeration.

Splunk SPL Query

index=web sourcetype=access_combined
| where match(uri_path, "(?i)/(api|records|case|admin)")
| stats count min(_time) as first_seen max(_time) as last_seen values(status) as status_codes by src_ip, uri_path
| where status_codes=200 AND count > 20
| eval first_seen=strftime(first_seen, "%Y-%m-%d %H:%M:%S"), last_seen=strftime(last_seen, "%Y-%m-%d %H:%M:%S")
| sort - count

Tune the URI keyword list and count threshold to the deployed API surface and baseline traffic.

Wazuh OSSEC Rule

<group name="web,access_control,cve-2024-34320,">
  <rule id="100320" level="10">
    <decoded_as>web-accesslog</decoded_as>
    <url>/(api|records|case|admin)</url>
    <regex>] "?(GET|POST|PUT|DELETE|PATCH)</regex>
    <description>CVE-2024-34320: Suspicious access to ProPhoenix Law RMS sensitive API endpoint</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
  <rule id="100321" level="12" frequency="20" timeframe="60">
    <if_matched_sid>100320</if_matched_sid>
    <same_source_ip />
    <description>CVE-2024-34320: Repeated (>=20/60s) sensitive API access from same source - possible broken access control abuse</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

All detection content is generic to the vulnerability class. Because no endpoint paths or parameters are published, these rules must be mapped to the organization's actual logging fields and the specific sensitive API routes observed in the deployed ProPhoenix Law RMS instance before production use.

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix, fixed version, or workaround has been identified in the provided data. Treat all ProPhoenix Law RMS v2022.2403.3.101 deployments as vulnerable until the vendor confirms otherwise.

  1. Immediate mitigations

    • Remove direct internet exposure of the Law RMS API tier where operationally feasible; restrict access to trusted networks or a hardened access gateway.
    • Enforce authentication and authorization at a reverse proxy / API gateway in front of the application, applying explicit allow/deny rules per role so that the upstream mis-authorization cannot be reached by under-privileged callers. This is a compensating control, not a fix.
    • Apply least privilege to all API consumers and rotate credentials/API keys that may have been exposed.
    • Increase logging and alerting on all requests to records-management endpoints and monitor for anomalous reads/writes.
  2. Patch / upgrade steps

    • Contact ProPhoenix directly to obtain the current supported release and a statement on the access-control defect. No fixed version is published in the tracked data.
    • When a vendor fix becomes available, test and deploy it on an accelerated schedule, then verify the sensitive endpoints now enforce authorization for low-privilege and unauthenticated callers.
    • Until a fix exists, do not rely on version upgrades as a mitigation — none is documented.
  3. Long-term hardening

    • Adopt centralized, deny-by-default authorization for all API routes, with server-side enforcement of role and object scoping on every sensitive endpoint.
    • Add automated authorization test cases (privilege-escalation and IDOR checks) to the SDLC and to periodic penetration testing.
    • Deploy continuous API discovery and monitoring to catch newly exposed or mis-configured endpoints.
    • Maintain an asset inventory of internet-facing records-management systems and validate exposure on an ongoing basis.

References

No CISA KEV listing, threat-actor campaign, or exploit-in-the-wild evidence is associated with CVE-2024-34320 in the provided data. No public proof-of-concept or Nuclei template is available.

👁️ SHODAN DORKS (THREAT HUNTING)

What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.

product:"ProPhoenix"
title:"ProPhoenix"
product:"ProPhoenix" "2022.2403.3.101"
◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2024-34320/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.