CVE-2023-36255

What it actually does

CVE-2023-36255 is a remote code execution vulnerability in Eramba Enterprise and Community Edition 3.19.1 involving unsafe handling of the URL path parameter. A remote attacker with low-privileged access can submit a crafted request that causes attacker-controlled input to be interpreted by server-side code, resulting in arbitrary command or code execution in the context of the Eramba web application process. Successful exploitation can allow read/write access to application files, access to stored secrets available to the application, modification of risk/compliance data, lateral movement from the application host, and potential full system compromise depending on service permissions.

Why it matters to the business

Eramba is commonly used to manage governance, risk, compliance, audits, controls, assets, and security documentation, so compromise can expose sensitive risk and compliance records and undermine the integrity of security program evidence. Because exploitation is weaponized, the EPSS score is high, and the issue has been public for over 1,100 days, internet-accessible or broadly reachable Eramba deployments should be treated as high-priority even though the vulnerability is not currently listed in CISA KEV and is not marked as ransomware-associated.

How an attack unfolds

An attacker first obtains or uses a low-privileged Eramba account or valid session, which is consistent with the CVSS privilege requirement. The attacker then identifies an affected Eramba 3.19.1 instance and sends a crafted HTTP request containing a malicious path parameter in the URL. If the application passes that parameter into unsafe server-side logic, the payload can trigger execution of attacker-supplied commands or code under the web server or PHP application user. After initial execution, the attacker typically confirms command execution, enumerates the host, reads application configuration and database credentials, accesses sensitive governance/risk/compliance records, stages web shells or persistence, and may pivot to connected databases, file shares, or internal systems reachable from the Eramba host.

How to fix it

Upgrade Eramba Enterprise or Community Edition to the latest vendor-supported release. No fixed version was provided in the input, so security teams should consult Eramba’s official release notes and advisories and avoid remaining on version 3.19.1. If immediate upgrade is not possible, restrict Eramba access to trusted networks or VPN, enforce strong authentication and MFA where supported, remove unnecessary low-privileged accounts, rotate credentials stored or used by the application, and apply web application firewall rules or reverse-proxy filters that block suspicious path parameter values containing command separators, traversal sequences, shell metacharacters, or encoded equivalents. Also ensure the web server/PHP process runs with least privilege, disable outbound network access from the application host where not required, and monitor for web server child processes spawning shells or system utilities.

How to confirm the fix worked

Confirm all Eramba instances are inventoried and no deployment remains on Eramba Enterprise or Community Edition 3.19.1. Validate the deployed version through the application UI, package metadata, container image tags, source release information, or vendor-supported version checks. Review reverse proxy and web access logs to verify requests with suspicious path parameters are blocked or rejected after mitigation. If a compensating WAF rule is used, test with benign payloads containing URL-encoded command separators and traversal sequences and confirm they are denied before reaching the application. After upgrade, run an authenticated vulnerability scan or controlled security test to confirm the path parameter no longer results in command execution and that application functionality remains intact.

Typical attack path

1. Identify an exposed or reachable Eramba Enterprise or Community Edition deployment.
2. Obtain valid low-privileged credentials or reuse an existing authenticated session.
3. Confirm the target is running an affected Eramba version, especially 3.19.1.
4. Send a crafted HTTP request containing a malicious path parameter in the URL.
5. Execute a harmless command first to confirm code execution, then run discovery commands.
6. Read application configuration, credentials, uploaded files, and compliance/risk data accessible to the application user.
7. Deploy a web shell or other persistence mechanism if write permissions allow.
8. Use recovered secrets and network access from the Eramba host to move laterally or access backend services.

How to detect it

Investigate whether exploitation already occurred by reviewing HTTP access logs from reverse proxies, load balancers, WAFs, Apache, nginx, and application logs for requests containing a path query parameter with shell metacharacters, command separators, traversal patterns, or URL-encoded equivalents. Correlate suspicious requests with authenticated Eramba user sessions, especially low-privileged users performing unusual actions or accessing uncommon endpoints. On the host, review PHP-FPM, web server, auditd/sysmon/EDR, shell history, cron, temporary directories, and web application directories for evidence that the web server user spawned command interpreters or downloaded tools. Look for child processes of apache2, httpd, nginx, php-fpm, or php invoking sh, bash, curl, wget, python, perl, nc, or similar utilities. Examine recent file writes under the Eramba installation, upload, cache, tmp, and webroot directories for web shells or unfamiliar PHP files. If compromise is suspected, preserve logs and disk artifacts before remediation, isolate the host, and rotate credentials used by the application.

• path=
• path=../
• path=..%2F
• path=%2e%2e%2f
• path=;
• path=%3B
• path=|
• path=%7C
• path=`
• path=%60
• path=$(
• path=%24%28
• path=%26%26
• path=&&
• path=%0a
• path=%0d
• /bin/sh
• /bin/bash
• bash -c
• sh -c
• curl http
• wget http
• python -c
• perl -e
• nc -e
• php -r
• www-data
• apache2 -> /bin/sh
• httpd -> /bin/sh
• nginx -> /bin/sh
• php-fpm -> /bin/sh

What your security team should do

• Prioritize remediation for any internet-facing or broadly reachable Eramba instance because exploitation is weaponized and the EPSS likelihood is elevated.
• Upgrade Eramba to the latest supported release and remove or isolate any remaining version 3.19.1 deployments.
• Require authenticated access through VPN, SSO, or trusted network paths where feasible, and enforce MFA for administrative and user accounts.
• Review Eramba user accounts for stale, shared, default, or low-privileged accounts that could be abused to meet the privilege requirement.
• Rotate application secrets, database credentials, API keys, and service credentials if exploitation is suspected or cannot be ruled out.
• Search historical web, application, proxy, EDR, and OS logs for suspicious path parameter payloads and web server process execution.
• Harden the host by ensuring the web application user has minimal filesystem permissions and limited outbound network access.
• Add SIEM detections for suspicious path parameter values, web server spawning shells, and unexpected files written under Eramba web-accessible directories.