CVE-2021-27068
High · 8.8CVSS
8.8
EPSS
53.6%
Published
May 11, 2021
CISA due date
—
Cloudanix analysis
A vulnerable software component could let a low-privileged attacker take control of an affected application unless it is updated.
- Exploitation
- Remote Authenticated
- Attacker needs
- Low Privilege
- Complexity
- Moderate
- Impact
- Remote Code Execution
- Component
- Application
- Class
- RCE
- Remediation
- Patch
- Effort
- Low
- Patch risk
- Low
What it actually does
This is a remote code execution flaw with network attack vector, low attack complexity, and no user interaction required. Based on the provided CVSS vector, exploitation requires low-privileged access and can allow an attacker to execute arbitrary code in the context of the affected process or application using the vulnerable component. Successful exploitation can compromise confidentiality, integrity, and availability by allowing command execution, application tampering, data access, or service disruption.
Why it matters to the business
An exposed vulnerable deployment can allow a low-privileged attacker to take control of the affected application or development/runtime component, potentially leading to data theft, service outages, deployment pipeline compromise, or lateral movement. Although it is not listed in CISA KEV and no ransomware association is provided, the EPSS score is elevated at 0.53582 and the issue has been public for over five years, so security teams should assume exploit knowledge may be available and prioritize remediation where the affected component is reachable by untrusted or semi-trusted users.
How an attack unfolds
An attacker first identifies an application or service using the vulnerable affected product, then obtains or uses low-privileged access if required by the deployment. The attacker sends a crafted network request or input that reaches the vulnerable code path in the affected component. If exploitation succeeds, the component executes attacker-controlled code under the privileges of the running process. The attacker can then run reconnaissance commands, write web-accessible files or tooling, access configuration secrets, modify application behavior, create persistence, and attempt lateral movement to adjacent systems or build/deployment infrastructure.
How to fix it
Upgrade the affected component to a fixed release or source revision. For the supplied affected product, update laminas/laminas-http to a version that includes commit 298f732e1acb031db70ea4fd2133a283b2a4a65e or later. Rebuild and redeploy applications that vendor, bundle, or statically package the vulnerable dependency. Remove stale dependency copies from containers, application images, build artifacts, and deployment packages. If immediate upgrade is not possible, restrict access to the affected functionality, require strong authentication, reduce process privileges, apply network segmentation, disable unnecessary routes or features that invoke the vulnerable code path, and use application allowlisting or runtime controls to limit post-exploitation command execution.
How to confirm the fix worked
Confirm remediation by checking dependency manifests, lockfiles, software composition analysis results, and deployed artifact contents for laminas/laminas-http and verifying that the installed source includes commit 298f732e1acb031db70ea4fd2133a283b2a4a65e or a later fixed version. Rebuild containers and application packages from clean dependency caches, then rescan the final runtime image rather than only the source repository. Validate that no older copies remain in vendor directories, package caches, release bundles, or inactive deployment slots. Where safe and authorized, perform a targeted security test against the previously exposed code path to confirm the crafted input no longer results in command execution or abnormal application behavior.
Typical attack path
- Identify internet-facing or internally reachable applications using the vulnerable affected component.
- Obtain or use low-privileged application access if required by the target exposure model.
- Send crafted network input that exercises the vulnerable code path.
- Achieve code execution in the security context of the affected application or process.
- Run operating system and application reconnaissance commands.
- Access sensitive files, credentials, environment variables, or application secrets.
- Deploy persistence, web shells, reverse shells, or additional tooling if permitted by host controls.
- Pivot to databases, internal services, source repositories, CI/CD systems, or other reachable assets.
How to detect it
Review application, web server, reverse proxy, authentication, endpoint, EDR, and container runtime logs for activity consistent with remote code execution. Focus on the period before remediation and on systems where the affected component was reachable. Look for malformed or unusual requests followed by application errors, crashes, unexpected outbound network connections, or child processes spawned by web/application runtimes. On Linux, inspect process execution telemetry for shells or download utilities launched by PHP, web server, or application worker processes; on Windows, look for command interpreters or scripting engines launched by service or application processes. Review file integrity data for newly created files in web roots, temporary directories, upload directories, vendor directories, and application cache directories. Correlate suspicious requests with subsequent DNS queries, HTTP callbacks, reverse shell attempts, credential access, configuration file reads, or deployment artifact modification. Because no KEV or named threat actor context is provided, detection should emphasize behavioral indicators of exploitation rather than relying on a known campaign signature.
- /bin/sh -c
- /bin/bash -c
- bash -i
- sh -i
- cmd.exe /c
- powershell -enc
- powershell -EncodedCommand
- certutil -urlcache -f
- curl http://
- wget http://
- nc -e
- ncat -e
- python -c
- python3 -c
- perl -e
- php -r
- /tmp/.
- /var/tmp/.
- /dev/shm/
- www-data
- apache
- nginx
What your security team should do
- Prioritize patching internet-facing or partner-accessible deployments first, especially where low-privileged users can reach the affected functionality.
- Inventory all applications, containers, and build artifacts for laminas/laminas-http and verify whether they include the fixed commit 298f732e1acb031db70ea4fd2133a283b2a4a65e or later.
- Treat affected systems as potentially exposed because the vulnerability has been public for a long period and has an elevated EPSS score, even though it is not currently listed in CISA KEV.
- Hunt for signs of post-exploitation activity such as unexpected child processes spawned by web or application runtimes, new web-accessible files, suspicious outbound connections, and credential access.
- Rotate secrets, API keys, and credentials accessible to any application where exploitation is suspected or cannot be ruled out.
- Apply least-privilege runtime controls so the affected application process cannot write broadly, execute shell utilities unnecessarily, or reach sensitive internal services.
- Add dependency governance checks to prevent reintroduction of vulnerable versions through transitive dependencies, vendored code, or stale container layers.
The record
Visual Studio Remote Code Execution Vulnerability
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|