dbcve.org
OS Command InjectionWeakness · CWE-78

CVE-2014-125124

CRITICAL · 10.0 CVSS v4.0 Published 2025-07-31
Mitigation only
No fix yet — a mitigation exists. There is no fixed release. A documented workaround reduces exposure in the meantime.
See remediation →
100/100
Remediation priority · Urgent
Public exploit Remotely reachable No privileges Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
An unauthenticated remote command execution vulnerability exists in Pandora FMS versions up to and including 5.0RC1 via the Anyterm web interface, which listens on TCP port 8023. The anyterm-module endpoint accepts unsanitized user input via the p parameter and directly injects it into a shell command, allowing arbitrary command execution as the pandora user. In certain versions (notably 4.1 and 5.0RC1), the pandora user can elevate privileges to root without a password using a chain involving the artica user account. This account is typically installed without a password and is configured to run sudo without authentication. Therefore, full system compromise is possible without any credentials.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

Unauthenticated command injection in Pandora FMS Anyterm web interface (port 8023) via the p parameter in the anyterm-module endpoint, allowing remote attackers to execute arbitrary commands as the pandora user. In versions 4.1 and 5.0RC1, the pandora user can escalate to root through a passwordless artica user account configured with passwordless sudo access.

MitigationImmediately restrict network access to port 8023 or disable the Anyterm interface, upgrade Pandora FMS beyond 5.0RC1 to a patched version, and remove/disable the passwordless artica user or disable its passwordless sudo access.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
None
Authentication
X
User interaction
None
Scope
X

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Verify if port 8023 is open and the Anyterm interface is reachable
    Scan the local host or target system for open port 8023 using a network scanner (such as nmap) or by running a command like 'netstat -tlnp | grep 8023' or 'ss -tlnp | grep 8023' to confirm the Anyterm service is listening
    Affected if Port 8023 is open and responding, indicating the Anyterm web interface is active and potentially exposed
  2. Determine the installed Pandora FMS version
    Check the Pandora FMS version by examining the package manager output (dpkg, rpm), the web interface version display, or configuration files that typically contain version metadata
    Affected if The installed version is 4.1 or 5.0RC1, matching the vulnerable versions listed in the CVE summary
  3. Confirm the pandora system user exists
    Check for the existence of the pandora user on the system by inspecting /etc/passwd or using the 'id pandora' or 'getent passwd pandora' commands
    Affected if The pandora user exists on the system, which would be the context for command execution if the vulnerability is exploited
  4. Check for the existence of the artica user with passwordless sudo access
    Examine /etc/sudoers or files in /etc/sudoers.d/ for an entry granting the artica user passwordless sudo privileges, or use 'sudo -l -U artica' to list artica user's sudo permissions
    Affected if An artica user account exists with passwordless sudo access configured, which would enable privilege escalation from the pandora user to root as described in the vulnerability summary

A system is affected if it runs Pandora FMS version 4.1 or 5.0RC1 with the Anyterm interface accessible on port 8023 and includes the vulnerable configuration with the artica user having passwordless sudo access.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Mitigation available No clean upgrade yet — mitigate in the meantime
Mitigation

Immediately restrict network access to port 8023 or disable the Anyterm interface, upgrade Pandora FMS beyond 5.0RC1 to a patched version, and remove/disable the passwordless artica user or disable its passwordless sudo access.

Recommended fix Moderate confidence

Upgrade to Pandora FMS 5.1 or later stable release

  1. 1. Identify and document all Pandora FMS installations in the environment and their current versions.
  2. 2. If running Anyterm service on port 8023, disable or firewall the service immediately to block external access.
  3. 3. Upgrade Pandora FMS from version 5.0RC1 or earlier to the latest stable release (5.1 or later) that includes the security fix for the Anyterm command injection vulnerability.
  4. 4. After upgrade, verify the Anyterm module no longer accepts unsanitized input via the p parameter.
  5. 5. Change passwords for all system accounts, especially the artica user account which was found without a password.
  6. 6. Review and secure sudo configurations to prevent privilege escalation from the pandora or artica users to root.
  7. 7. Apply least-privilege permissions to the pandora user account.
  8. 8. After remediation, conduct penetration testing to verify the vulnerability is closed.
Caveat Before upgrading, review release notes for database migration requirements and potential configuration changes between 5.0RC1 and 5.x versions. Test in a non-production environment first.

Generated from the published advisory — verify against the referenced sources before acting.

Have this fixed Scoped from the published advisory
  • Consultation3.0 h
  • Implementation6.0 h
  • Testing3.0 h
  • Review / QA2.0 h
14.0 hours of engineering $2,490
Get help mitigating

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $3,984.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2014-125124 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2014-125124 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data