01 · The Real Story
Like finding a lockpick that only works on a discontinued safe model nobody owns
CVE-2026-40523 is a SQL injection in FrontAccounting's Audit Trail report handler (reporting/rep710.php). An authenticated user holding the SA_GLANALYTIC role can inject payloads via the PARAM_2 and PARAM_3 POST parameters. The unsanitized inputs flow into a WHERE clause, enabling time-based blind extraction via SLEEP() amplified across JOINs, or direct UNION-based data exfiltration of credentials, financial records, and anything else in the MySQL backend. All FrontAccounting versions prior to 2.4.20 (released 2026-04-28) are affected.
The vendor rates this HIGH at 8.1, and in a vacuum a network-reachable authenticated SQLi *does* merit that score. But CVSS doesn't account for installed base, attacker motivation, or real-world exposure. FrontAccounting is a free, open-source PHP/MySQL ERP with roughly 30 tracked enterprise adopters globally (Enlyft) and about 117 SourceForge downloads per week. It is overwhelmingly deployed by small businesses with fewer than 50 employees. For an enterprise managing 10,000 hosts, the probability of even *having* a FrontAccounting instance is near zero. The authentication + specific role requirement further narrows the attack surface to insider threat or a post-compromise scenario. The vendor severity dramatically overstates the real-world risk for any enterprise patch queue.
"Authenticated SQLi in a niche open-source ERP used by ~30 companies worldwide. Backlog it."
02 · The Attack Path
4 steps from start to impact.
STEP 01
Obtain authenticated session with SA_GLANALYTIC role
The attacker must possess valid FrontAccounting credentials for an account granted the
SA_GLANALYTIC permission. This role is typically assigned to accounting analysts and financial auditors who need access to General Ledger analytics and audit trails. The attacker either compromises such an account through credential stuffing, phishing, or is a malicious insider.Conditions required:
- Valid FrontAccounting credentials
- Account must hold SA_GLANALYTIC permission
Where this breaks in practice:
- FrontAccounting is a niche product with ~30 known enterprise deployments — most attackers will never encounter it
- SA_GLANALYTIC is a specific accounting role, not a default user permission
- Most instances are internal-only, behind VPN or firewall
Detection/coverage: Web application login logs; anomalous access from unusual IPs or geolocations
STEP 02
Navigate to Audit Trail report endpoint
The authenticated attacker sends a POST request to
/reporting/rep710.php, the Audit Trail report handler. This is a standard report generation page within the FrontAccounting UI. No special tooling is required — a browser or curl suffices.Conditions required:
- Active authenticated session from Step 1
- Network access to the FrontAccounting web interface
Where this breaks in practice:
- Endpoint is only accessible to authenticated users with the correct role
- No public exploit tooling or Metasploit module exists for this specific CVE
Detection/coverage: WAF rules detecting SQLi patterns in POST parameters; application-level audit logging of report generation requests
STEP 03
Inject SQL via PARAM_2 or PARAM_3
The attacker crafts a malicious POST body with SQL injection payloads in the
PARAM_2 and/or PARAM_3 fields. These parameters are concatenated directly into SQL WHERE clauses without parameterization. UNION-based injection can immediately return data rows (usernames, password hashes, financial records) rendered into the PDF report output. Time-based blind injection via SLEEP() confirms injectability and can exfiltrate data character-by-character.Conditions required:
- Successful authentication and authorization from Steps 1-2
- Knowledge of the MySQL schema (open-source, so publicly available)
Where this breaks in practice:
- Standard WAF rules catch UNION SELECT and SLEEP() patterns
- MySQL user privileges may limit what the injected queries can reach
Detection/coverage: SQL injection signatures in WAF/IDS; MySQL slow query log showing SLEEP() calls; anomalous PDF report generation times
STEP 04
Exfiltrate data or cause denial of service
With UNION-based injection, the attacker extracts credentials, financial data, and configuration from the MySQL database, all rendered into a downloadable PDF. Alternatively, amplified
SLEEP() calls across JOIN result sets exhaust MySQL connection pools, causing denial of service for the entire FrontAccounting instance. The blast radius is limited to the single FrontAccounting application and its database.Conditions required:
- Successful SQL injection from Step 3
Where this breaks in practice:
- Blast radius is limited to one small-business accounting application
- Data value is typically one SMB's financial records — not fleet-scale or identity-scale
- DoS only affects the FrontAccounting instance, not broader infrastructure
Detection/coverage: Database connection pool exhaustion alerts; anomalous data volumes in PDF report downloads; MySQL query monitoring
03 · Compensating Control
1
LOW 3.0→IGNORE 0.0
SEVERITY REDUCEDUpgrade to FrontAccounting 2.4.20 — The definitive fix. Version 2.4.20 parameterizes the vulnerable query in
rep710.php. Since FrontAccounting is a self-hosted PHP app, the upgrade is a file replacement operation. Per the noisgate remediation SLA for LOW severity, treat this as backlog hygiene with no hard deadline, but aim to include it in your next maintenance window.2
LOW 3.0→IGNORE 1.0
SEVERITY REDUCEDDeploy WAF rules blocking SQLi in POST parameters to /reporting/rep710.php — A ModSecurity or cloud WAF rule matching UNION, SELECT, SLEEP, and BENCHMARK patterns in PARAM_2/PARAM_3 POST fields will block the known injection vectors. This buys time if you cannot immediately upgrade. Residual risk drops because the primary injection technique is neutralized, though exotic bypass techniques remain theoretically possible.
3
LOW 3.0→LOW 2.5
Restrict SA_GLANALYTIC role assignment — Audit FrontAccounting user accounts and remove the SA_GLANALYTIC permission from any account that does not strictly require audit trail access. Reducing the number of accounts that can reach the vulnerable endpoint proportionally reduces the attack surface from insider threats or credential compromise.
4
LOW 3.0→LOW 2.0
Restrict network access to FrontAccounting to VPN/internal only — If FrontAccounting is currently exposed to the internet (unlikely but possible), place it behind a VPN or firewall rule limiting access to authorized internal networks. This eliminates the network attack vector entirely for external adversaries.
What doesn't work
- MySQL privilege hardening alone — while restricting the FA database user's permissions (e.g., removing FILE, PROCESS, SUPER) limits post-exploitation impact, it does not prevent data extraction from the FA database itself. The attacker can still UNION SELECT all tables the application user can read, including credentials and financial data.
- PHP input validation at the application layer — FrontAccounting's own input handling is the root cause. Adding a custom PHP filter would be fragile, version-specific, and likely overwritten on the next update. Use a WAF instead.
- Database activity monitoring without blocking — DAM tools will alert on suspicious queries but won't prevent data exfiltration in a time-based blind scenario where the attacker works slowly. Detection is useful but not a compensating control for prevention.
04 · Intelligence Metadata
The supporting signals.
| In-the-Wild Exploitation | No known exploitation. Not listed in CISA KEV. No campaigns or threat actor activity reported. GreyNoise shows no scanning activity targeting FrontAccounting endpoints. |
|---|---|
| Proof-of-Concept Availability | No public PoC found. Checked pocindex.io aggregator, GitHub (no repos named CVE-2026-40523), ExploitDB, and nuclei templates — no dedicated exploit code. The JivaSecurity writeup describes the technique but a standalone weaponized PoC has not surfaced. However, SQL injection is trivial to reproduce from the advisory description alone. |
| EPSS Score | 0.00473 (0.47%) — bottom quartile. FIRST's model rates this as very unlikely to be exploited in the next 30 days, consistent with the niche product and auth requirement. |
| KEV Status | Not listed. No CISA KEV entry as of 2026-10-02. |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H (8.1 HIGH). VulnCheck also lists CVSS v4.0 at 7.2. Network-reachable, low complexity, requires low privileges, no user interaction. High confidentiality and availability impact, no integrity impact. The scope is unchanged — damage stays within the vulnerable component. |
| Affected Versions | All FrontAccounting versions prior to 2.4.20. This includes the 2.4.x branch and likely earlier major versions (2.3.x and below) that share the same reporting codebase. |
| Fixed Version | 2.4.20 (released 2026-04-28 on SourceForge). Patch commit: 647a181. No distro backports are relevant — FrontAccounting is not packaged in major Linux distributions. |
| Installed Base / Exposure | Negligible. Enlyft tracks ~30 companies using FrontAccounting globally. SourceForge shows ~117 downloads/week. Market share is 0.0-0.1% of accounting software. No significant Shodan/Censys/FOFA footprint. Overwhelmingly small businesses with <50 employees. |
| Disclosure Date | 2026-06-29. Advisory published with vendor fix already available (2.4.20 released 2026-04-28, two months prior). |
| Researcher | Jiva (JivaSecurity). Also credited with CVE-2026-40522 and CVE-2026-40524 — a batch of three SQLi findings in FrontAccounting's reporting module. |
Sources.
05 · The Call
Final Verdict
↓ DOWNGRADED to LOW (3.0/10)
Why this verdict
- Authentication + role gate: The attack requires valid credentials AND the
SA_GLANALYTICpermission — this is not a default role. An attacker must either be a malicious insider or have already compromised an account, which presupposes prior access and credential theft. This is a post-authentication, role-gated attack — each precondition compounds downward. - Negligible installed base: FrontAccounting has approximately 30 tracked enterprise deployments globally and commands 0.0% market share. For an enterprise managing 10,000 hosts, the probability of running FrontAccounting is effectively zero. The vendor's HIGH rating assumes broad applicability that does not exist.
- No exploitation signals: Zero CISA KEV listing, zero GreyNoise scanning activity, zero known campaigns, EPSS at 0.47% (bottom quartile). No weaponized PoC exists. The vulnerability has been public for 3+ months with no uptake by threat actors.
- Role multiplier: FrontAccounting is a line-of-business accounting application for small businesses. It does NOT occupy any high-value role in the deployment-role catalog: it is not an identity provider, hypervisor, CI/CD system, backup system, network edge appliance, or kernel-mode agent. The blast radius of successful exploitation is confined to one SMB's financial database — host-level at absolute worst, application-level in practice. No high-value-role floor applies.
- Blast radius is application-scoped: Even successful exploitation yields one small company's financial records or a DoS of a single PHP app. There is no lateral movement, no domain compromise, no fleet-scale impact. The MySQL user typically has limited privileges scoped to the FA database.
Why not higher?
The vendor's HIGH (8.1) reflects the raw technical severity of a network-reachable SQLi, which is fair in isolation. But real-world severity must account for the authentication prerequisite (PR:L with a specific role gate), the near-zero installed base (~30 companies), the absence of any exploitation activity or PoC weaponization, and the lack of any high-value deployment role. None of the floor-override conditions apply — FrontAccounting is not a canonical high-value-role component, and no installed-base evidence suggests otherwise.
Why not lower?
IGNORE would understate the risk for the handful of organizations that actually run FrontAccounting. SQL injection is a well-understood, reliably exploitable vulnerability class — an insider with the right role could trivially dump the entire financial database. The fix is available and the advisory is clear. For the ~30 organizations that use FA, this deserves at least backlog attention, not complete dismissal.
06 · Verification
Crowdsourced verification payload.
Run this script on the FrontAccounting web server host as any user with read access to the FA installation directory. Invoke with: bash check_cve_2026_40523.sh /var/www/html/frontaccounting (adjust the path to your FA installation root). No special privileges required beyond filesystem read access.
#!/bin/bash
# CVE-2026-40523 checker for FrontAccounting
# Usage: bash check_cve_2026_40523.sh /path/to/frontaccounting
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -euo pipefail
FA_DIR="${1:-/var/www/html/frontaccounting}"
VULN_FILE="$FA_DIR/reporting/rep710.php"
if [ ! -d "$FA_DIR" ]; then
echo "UNKNOWN - FrontAccounting directory not found at $FA_DIR"
exit 2
fi
if [ ! -f "$VULN_FILE" ]; then
echo "UNKNOWN - Vulnerable file rep710.php not found at $VULN_FILE"
exit 2
fi
# Method 1: Check for the patch commit signature
# The fix parameterizes PARAM_2 and PARAM_3 inputs
# Before fix: direct concatenation of $from and $to into SQL
# After fix: uses db_escape() or prepared statements
if grep -qP '\bdb_escape\b' "$VULN_FILE" 2>/dev/null; then
echo "PATCHED - rep710.php contains db_escape() sanitization (CVE-2026-40523 fix applied)"
exit 0
fi
# Method 2: Look for raw variable interpolation in SQL strings
if grep -qP 'PARAM_[23].*\$' "$VULN_FILE" 2>/dev/null || grep -qP '\$from|\$to' "$VULN_FILE" 2>/dev/null; then
# Try to find version from changelog or config
VERSION="unknown"
for vf in "$FA_DIR/CHANGELOG.txt" "$FA_DIR/config.php" "$FA_DIR/includes/session.inc"; do
if [ -f "$vf" ]; then
VER=$(grep -oP '2\.4\.\d+' "$vf" 2>/dev/null | tail -1)
if [ -n "$VER" ]; then
VERSION="$VER"
break
fi
fi
done
echo "VULNERABLE - FrontAccounting $VERSION has unpatched rep710.php (CVE-2026-40523)"
exit 1
fi
echo "UNKNOWN - Could not determine patch status of rep710.php"
exit 2