A transit portal stores user uploads under a web-accessible directory where the server will execute matching scripts. Why is this combination a critical finding class?
Select an answer to reveal the explanation.
Short Explanation
Leaving a loaded tool on a public shelf is different from locking it in a vault. Uploads that sit in an executable webroot can be fetched and run like pages. That location-plus-execution combo is why upload findings go critical fast.
Full Explanation
Storing user uploads under a web-accessible directory where the server will execute matching scripts is critical because executable webroot storage can turn a malicious upload into remote code execution. A transit portal that combines weak upload validation with an executing webroot gives adversaries a direct path from file write to server control—threatening schedules, payments, and rider data backends.
Uploads do not “always cause XSS in PDF readers” as the universal reason this is critical. Object storage does not always disable HTTPS for blobs. Web-accessible paths do not automatically fix broken access control; they often worsen impact when execution is possible.
Exam caveat: separate “can upload” from “can execute”—both must be true for classic upload-to-RCE; remediation usually removes execution from upload locations. CPTS web severity spikes when civic upload dirs are executable.
Operational check: move uploads outside executable document roots or disable script handlers there, serve via non-executing handlers/object storage, retest that uploaded scripts do not run, and monitor for new files in transit webroots. After relocating transit uploads, attempt to request a previously uploaded script via the web and confirm it downloads as inert bytes, not executed output.