CVE-2021-41950

What it actually does

This is an unauthenticated path traversal flaw in a web-accessible endpoint that uses attacker-controlled path components when handling tile resources. By supplying traversal sequences in the provider and variant parameters to pages/ajax/tiles.php, a remote attacker can cause the application to resolve paths outside the intended resource directory and delete arbitrary files that the web server process can write to. The primary impacts are integrity loss and availability loss: configuration files, application source files, cached assets, or other writable server-side files may be removed, potentially breaking the application or forcing recovery from backup. The CVSS 9.1 rating and high EPSS indicate the issue is severe and has meaningful exploitation likelihood where exposed.

Why it matters to the business

Successful exploitation can take a public-facing content or asset management application offline without requiring credentials, disrupting publishing workflows, access to media assets, and dependent business processes. If configuration or application files are deleted, recovery may require restoring from backups, redeploying the application, rotating secrets if configuration integrity cannot be trusted, and validating data consistency. Although this flaw is not primarily a data-theft issue, it can create significant operational downtime and incident-response cost. Public exploit availability and a high EPSS score make exposed, unpatched internet-facing systems a priority even though the issue is not listed in CISA KEV.

How an attack unfolds

An attacker first identifies a reachable vulnerable application and confirms that the tiles AJAX endpoint is accessible without authentication. They then send crafted HTTP requests to pages/ajax/tiles.php with provider and/or variant values containing directory traversal sequences such as ../ or URL-encoded equivalents. If the vulnerable code fails to normalize and constrain the resulting path to the intended tile directory, the request causes the server-side deletion routine to target files elsewhere on the filesystem. The attacker may begin with low-impact test paths to infer behavior from HTTP status codes, application errors, or missing resources, then target higher-impact files such as configuration files, source files, cache files, or other writable application components. After deletion, the application may return errors, fail to load modules, lose configuration, or become unavailable to all users.

How to fix it

Upgrade or patch affected deployments immediately. For the affected orchardcms/orchardcore Git package data provided, ensure the codebase includes fix commit b7096af1028d8f909f63dd076d1bbd573913a92d or a later trusted version containing that fix. For ResourceSpace deployments matching the vulnerability description, upgrade to ResourceSpace 9.6 revision 18277 or later. Where immediate upgrade is not possible, restrict access to pages/ajax/tiles.php at the web server or WAF layer, require authentication for the endpoint if compatible with business functionality, block traversal patterns in provider and variant parameters, and ensure the application process runs with the minimum filesystem permissions required. Remove write permissions from application source and configuration directories wherever possible, keep immutable deployment artifacts read-only, and maintain tested backups for rapid restoration.

How to confirm the fix worked

Confirm the deployed application version or Git commit includes the fixed code, specifically commit b7096af1028d8f909f63dd076d1bbd573913a92d for the provided Orchard Core package data or ResourceSpace 9.6 rev 18277 or later for ResourceSpace deployments. Review the patched code path to verify provider and variant inputs are canonicalized, traversal sequences are rejected, resolved paths are constrained to an approved base directory, and deletion operations cannot target arbitrary filesystem locations. From an external test perspective, requests to pages/ajax/tiles.php containing ../, ..%2f, %2e%2e%2f, or similar encoded traversal in provider or variant should be rejected, sanitized, or return a safe error without deleting any file. Validate filesystem permissions by confirming the web application identity cannot modify application source, configuration, or deployment files. Finally, monitor application logs after patching to confirm no continued traversal probes are succeeding.

Typical attack path

1. Discover an exposed vulnerable web application through scanning, fingerprinting, or known deployment URLs.
2. Probe pages/ajax/tiles.php to confirm the endpoint is reachable without authentication.
3. Send requests with crafted provider and variant parameters containing path traversal sequences or encoded traversal sequences.
4. Observe response codes, error messages, or application behavior to determine whether file deletion occurred.
5. Target writable configuration, source, cache, or application files to impair integrity or availability.
6. Trigger or wait for application failures caused by missing files, resulting in denial of service or degraded functionality.

How to detect it

Review web server, reverse proxy, WAF, CDN, and application logs for unauthenticated requests to pages/ajax/tiles.php containing provider or variant parameters with path traversal patterns. Search for plain and encoded traversal strings including ../, ..\, %2e%2e%2f, %2e%2e%5c, double-encoded variants, and mixed slash encodings. Correlate suspicious requests with sudden 500 errors, missing-file exceptions, configuration load failures, application restarts, deployment health-check failures, or unexpected 404s for previously available static/application resources. On hosts, compare application directories against a known-good release or package manifest and look for recently deleted or missing configuration, source, cache, and tile-related files around the request timestamps. Review file integrity monitoring, EDR telemetry, auditd, Sysmon, or OS file access audit logs for delete operations performed by the web server or application worker account. If exploitation is suspected, preserve access logs and application logs, snapshot the filesystem state, identify the process identity that performed deletions, and restore only from trusted backups or redeploy clean artifacts.

• pages/ajax/tiles.php
• provider=../
• variant=../
• provider=..%2f
• variant=..%2f
• provider=%2e%2e%2f
• variant=%2e%2e%2f
• provider=..%5c
• variant=..%5c
• provider=%2e%2e%5c
• variant=%2e%2e%5c
• GET /pages/ajax/tiles.php
• POST /pages/ajax/tiles.php
• /pages/ajax/tiles.php?provider=
• /pages/ajax/tiles.php?variant=
• provider=....//
• variant=....//
• provider=..%252f
• variant=..%252f

What your security team should do

• Prioritize internet-facing deployments for emergency patching because the flaw is unauthenticated, remotely reachable, high severity, and has public exploit availability with high EPSS.
• Inventory applications for exposure of pages/ajax/tiles.php and confirm whether any instance is running an affected version or missing the fixed commit/revision.
• Apply the vendor fix: include commit b7096af1028d8f909f63dd076d1bbd573913a92d or later for the provided Orchard Core package data, and use ResourceSpace 9.6 rev 18277 or later where applicable.
• Add temporary WAF or reverse-proxy rules blocking traversal sequences in provider and variant parameters until patching is verified.
• Harden filesystem permissions so the web server process cannot delete application code, configuration files, or other critical deployment artifacts.
• Search historical web access logs for traversal attempts against pages/ajax/tiles.php, especially unauthenticated requests with provider or variant parameters containing encoded or plain ../ sequences.
• If suspicious requests are found, perform file integrity checks against known-good deployment artifacts and restore missing or modified files from trusted backups.
• Review backup and recovery readiness for affected applications, since exploitation may manifest primarily as file deletion and service outage.