Search the public rule index by CVE, GHSA, CWE, language, framework, author, or rule slug. Filter by language, framework, severity, confidence, license, and validation status.
Image filename sanitization extracts the file extension from an input name without validating that the extension belongs to an allowed image format. This can allow attackers to preserve dangerous extensions (such as .php) during image upload or import operations.
An uploaded file is saved directly from a generic Request instance without input validation. This can lead to unrestricted file uploads (CWE-434) and stored cross-site scripting (CWE-79) via dangerous file types such as SVG documents.
Client-supplied MIME types from `$_FILES[...]['type']` or uploaded file metadata can be spoofed in the HTTP request. Relying on client-controlled MIME types for validation allows attackers to upload arbitrary files. Use server-side inspection such as `finfo_file()`, `mime_content_type()`, or file signature/magic bytes verification instead.
File upload extension validation relies on a blacklist instead of an allowlist. Blacklists often fail to prevent uploading dangerous configuration files (such as .htaccess) or alternative executable extensions, leading to remote code execution.
The endpoint permits file uploads without visible authentication or authorization checks. Ensure that you apply `@UseGuards()`, evaluate the user session inside `fileFilter`, or pass the request context `@Req()` for manual validation to prevent unauthorized users from uploading arbitrary files.
Extracting a file extension using substring/slice from lastIndexOf('.') guarded only by includes('.') results in an empty extension when filenames have trailing dots, potentially bypassing extension validation.
The uploaded file is written directly to the filesystem using its original filename without validating the file extension or content. Validate the filename extension against an allowlist and verify the file content before saving to prevent arbitrary file upload vulnerabilities (CWE-434).
A validated filename is subsequently reassigned to an unvalidated value before being saved, potentially bypassing extension checks and directory traversal protections. Ensure that overriding variables are sanitized and re-validated.
Validating file extensions using only `guessExtension()` is insecure if the file is eventually saved with its original client name. An attacker can upload a file with a malicious extension (e.g., .php) containing spoofed file contents (e.g., GIF headers), bypassing the validation. Ensure you also validate `getClientExtension()` to prevent dangerous file uplo
Direct base64 encoding of an uploaded file without prior MIME type or content validation. If this base64 string is rendered inline as a data URI, unrestricted SVG uploads could lead to Stored XSS. Ensure the uploaded file is validated using `$validator->validate(...)` or functions like `getimagesize()` before reading its contents.
FileResponse is returned from a `{...:path}`-parameterized route without a `headers=` argument forcing `Content-Disposition: attachment` and `X-Content-Type-Options: nosniff`. Starlette derives Content-Type from the on-disk file extension, so if any user-influenced file (e.g. a cached upload) has an HTML or SVG extension on disk, the browser will render it i
Moving an uploaded file to an unvalidated path derived from a function parameter can lead to path traversal and arbitrary file write vulnerabilities. Adversaries might write or overwrite files on the server. Validate the target path to prevent directory traversal (`..`) or use `basename()` to secure the filename.
Moving an uploaded file to an unvalidated destination path can allow attackers to write arbitrary files (e.g., web shells) to the server via directory traversal sequences ('..') or absolute paths. Validate the destination path using 'basename()', 'realpath()', or strict string checks before moving the file.
An uploaded file is moved into a public_path() (web-accessible) directory inside a handler that does not perform Laravel validation ($request->validate([...]) or Validator::make(...)). When the stored filename's extension is taken from the client (e.g. getClientOriginalExtension() / getClientOriginalName()), an authenticated attacker can upload an executable
The regex token `php*` is being used inside a denylist alternation, but in PCRE `*` is a quantifier on the preceding character, so `php*` matches 'ph', 'php', 'phpp', ... and does NOT match '.php4', '.php7', or '.phps'. This is an incomplete list of disallowed inputs (CWE-184): attackers can upload/rename files with PHP-executable extensions like .php4 that
User profile update assigns custom avatar URL without validating file ownership or internal upload records, potentially allowing arbitrary external resource embedding.
ModSecurity file upload verification rules should include `t:removeWhitespace` to prevent bypasses via whitespace padding in file extensions.
Calling generic 'image.Decode' or 'image.DecodeConfig' dynamically dispatches image decoding based on magic bytes among all registered formats. Transitive dependencies may register decoders (e.g., TIFF) prone to excessive memory consumption or denial of service on untrusted inputs. Prefer using format-specific decoders (such as jpeg.Decode, png.Decode, gif.D
A function parameter is interpolated as a file extension into a filename f-string and then used to open or path-join a file, without first validating the parameter against an allowlist of permitted formats. Attackers can supply values such as "../../etc/cron.d/x" or dangerous extensions (".py", ".sh", ".php") to traverse outside the intended directory or wri
An uploaded file is accessed without prior validation. Direct usage of `FILES` without an explicit validation function can lead to unrestricted file uploads, enabling Stored XSS or Remote Code Execution. Ensure the file's MIME type and extension are securely validated before processing its attributes or saving it locally.
Serving uploaded media files using Django's `static()` without overriding the default view allows files to be served inline based on their inferred mimetype. This can lead to Stored XSS if users upload malicious HTML or SVG files. To mitigate this vector during local serving or debug testing, override the `view` parameter with a custom handler that enforces
A request parameter ($FILE_KEY) is used for file upload extraction but was not found within the `$REQ->validate(...)` rules explicitly checked within this scope. This parameter mismatch entirely bypasses file validation restrictions, potentially allowing attackers to upload malicious scripts and achieve Remote Code Execution.
wp_handle_upload() or wp_handle_sideload() was called without specifying an allowed MIME types array ('mimes' in overrides). This allows WordPress default upload MIME types to be processed, which may lead to arbitrary file upload or stored XSS when unprivileged users are permitted to upload files.
A validator is being registered or created inside the `initializeFormElement()` lifecycle hook. At this stage in the TYPO3 Form lifecycle, concrete form definition properties (such as `allowedMimeTypes`) have not yet been applied. This causes the validator to use default or incomplete data, completely bypassing intended security restrictions like server-side
