Remote code execution

It is not measured as a rate; you confirm a path exists. Evidence: a CVE entry tagged RCE for something you run, a request in the logs carrying shell syntax or a serialized object, an unexpected child process spawned by your web server such as sh or curl, or a new file written by the web user.

Test your own system only in staging, using the vendor's check or a harmless command with a timing difference such as sleep. Review server logs for the same string across the days before you noticed.

A Laravel app at a small SaaS runs an old debug-mode package. The access log has a request to /_ignition/execute-solution with a JSON body referencing a file path. Within a minute the process list shows php-fpm spawning bash and then wget fetching a .sh file from an unfamiliar host.

The attacker never had an account. The log line plus the child process is the proof. The team takes the host offline, rotates the app key and database password because the process could read .env, and rebuilds from a clean image.

SQL injection makes the database execute attacker-chosen queries; the attacker is limited to what the database account can do, though that can sometimes be stretched into command execution. Remote code execution means they are running code in the application or on the OS itself. SQLi often leaks data; RCE usually means full control.

Rating the bug by its entry point instead of its consequence. Thinking a web application firewall makes patching optional. Running the web server as root or with write access to its own code. Cleaning the dropped file but not rotating secrets in the environment. Assuming an unauthenticated RCE needs a targeted attacker, when scanners find it for them.

Patch the affected component first, then assume secrets in reach of the process are burned and rotate them. Run the web process as a low-privilege user, make the code directory read-only to it, and alert on shell binaries spawned by the web server.