FrontAccounting before 2

FrontAccounting is an open-source double-entry ERP/accounting suite popular with SMBs and a handful of NGOs. The Audit Trail report handler (under the GL analytics path) concatenates user-supplied parameters into a SQL string without sufficient parameterization, letting any user holding the SA_GLANALYTIC permission inject arbitrary SQL — including UNION-based data exfiltration of the users table (password hashes, session tokens) and stacked writes against the chart-of-accounts. All versions before 2.4.20 are affected; the fix lands in 2.4.20 (released alongside the 2026-06-29 advisory).

Vendor scored this 8.1 HIGH with vector AV:N/AC:L/PR:L/UI:N/C:H/I:N/A:H. The C:H and A:H are defensible — full DB read plus DROP-table-class writes — but the score ignores that FrontAccounting installs are almost never internet-exposed (most sit behind office VPNs or on-prem LAN), the privilege requirement is a real accounting role rather than a generic logged-in user, and the installed base is in the low tens of thousands globally per Shodan/Wappalyzer fingerprints. Real-world severity lands at MEDIUM.

Why this verdict

• Authenticated-only, role-gated: PR:L understates the friction — SA_GLANALYTIC is a finance role, not generic auth. Most tenants have <5 users with this bit.
• Tiny internet exposure: ~1,800 instances on Shodan; the vast majority of FA installs sit on office LAN or behind VPN, so external-attacker reachability is near zero.
• Role multiplier: FrontAccounting is canonically a line-of-business application tier (typical role b) — it is not an IdP, hypervisor, CA, backup server, or kernel-mode agent. Chain succeeds → blast radius is one tenant's accounting database, not domain or fleet. No high-value-role floor is triggered.
• No DB-to-OS pivot in-band: Default fa_user lacks FILE privilege; no INTO OUTFILE webshell, no xp_cmdshell equivalent. Impact is bounded to the FA schema.
• No active exploitation, no KEV, low EPSS: Disclosed yesterday, no PoC weaponization observed.
• Vendor patch is straightforward: Drop-in upgrade to 2.4.20, no schema migration listed.

Why not higher?

HIGH would require either internet-wide exposure (the Shodan count refutes this), unauthenticated access, or a high-value-role deployment (FA is not in the IdP/hypervisor/PAM/backup/edge catalog). None of those hold. Confidentiality impact alone, gated behind a finance role, is a textbook MEDIUM.

Why not lower?

LOW is wrong because the chain genuinely reaches password hashes, financial records, and tax/banking data in the FA database — material regulated-data exposure for any tenant that gets hit. The authenticated-insider abuse case is real (disgruntled accountant), and that alone keeps it above LOW.

1. Upgrade to FrontAccounting 2.4.20 — The clean fix. Tarball upgrade is in-place; back up the 0_ tables first. Deploy within the noisgate remediation SLA of 365 days, but realistically schedule inside the next change window — this is a small app.
2. Remove SA_GLANALYTIC from roles that don't need it — Audit 0_security_roles and strip the bit from clerical/data-entry roles. Reduces the population that can reach the vulnerable handler to a handful of named users.
3. Put the FA web tier behind VPN / SSO with MFA — If your FA is internet-exposed today, get it off the public internet before the report-handler URL is fingerprinted. SSO+MFA also defeats credential stuffing against the SA_GLANALYTIC accounts.
4. Apply WAF rules for SQLi on /reporting/rep710.php and /admin/audit_trail.php — ModSecurity CRS rules 942100–942999 block common UNION/boolean SQLi payloads. Not a substitute for patching but buys time until 2.4.20 deploys.
5. Restrict the FA DB user's privileges — Confirm fa_user has no FILE, PROCESS, SUPER, or cross-schema rights. Caps the blast radius if SQLi lands.
6. Force password rotation for FA admin/finance roles after patching — Assume hashes may have been exfiltrated by an insider during the exposure window. Rotate before re-enabling the audit-trail report.

Run on the FrontAccounting web/app host as any user with read access to the install directory. Invoke with the install path as the first argument, e.g. ./check_fa.sh /var/www/frontaccounting. No root required; reads config.php and version markers.

#!/usr/bin/env bash
# noisgate verification — CVE-2026-40523 FrontAccounting Audit Trail SQLi
# Usage: ./check_fa.sh /path/to/frontaccounting
set -u
FA_ROOT="${1:-}"
if [[ -z "$FA_ROOT" || ! -d "$FA_ROOT" ]]; then
  echo "UNKNOWN: pass FrontAccounting install dir as arg 1" >&2
  exit 2
fi

# 1. Try the canonical version file
VER=""
for f in "$FA_ROOT/config.default.php" "$FA_ROOT/config.php" "$FA_ROOT/version.php" "$FA_ROOT/CHANGELOG.txt"; do
  if [[ -f "$f" ]]; then
    V=$(grep -Eio '"2\.[0-9]+\.[0-9]+"|2\.[0-9]+\.[0-9]+' "$f" 2>/dev/null | head -n1 | tr -d '"')
    if [[ -n "$V" ]]; then VER="$V"; break; fi
  fi
done

if [[ -z "$VER" ]]; then
  echo "UNKNOWN: could not determine FrontAccounting version under $FA_ROOT"
  exit 2
fi

# semver compare against 2.4.20
IFS='.' read -r A B C <<<"$VER"
A=${A:-0}; B=${B:-0}; C=${C:-0}
FIXED_A=2; FIXED_B=4; FIXED_C=20

vulnerable=0
if (( A < FIXED_A )); then vulnerable=1; fi
if (( A == FIXED_A && B < FIXED_B )); then vulnerable=1; fi
if (( A == FIXED_A && B == FIXED_B && C < FIXED_C )); then vulnerable=1; fi

if (( vulnerable )); then
  echo "VULNERABLE: FrontAccounting $VER (< 2.4.20) — CVE-2026-40523"
  exit 1
else
  echo "PATCHED: FrontAccounting $VER (>= 2.4.20)"
  exit 0
fi

Sources

1. FrontAccounting GitHub releases (2.4.20)
2. CVE Details — FrontAccounting product page
3. CISA KEV catalog
4. FIRST EPSS scoring
5. CWE-89: SQL Injection
6. sqlmap project (authenticated SQLi tooling)
7. OWASP ModSecurity CRS SQLi ruleset
8. Shodan dorks reference