| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| WLED's GET /json/cfg endpoint (registered in wled00/wled_server.cpp) calls serveJson() with no settings-PIN check, unlike the /edit endpoint which explicitly checks correctPIN, disclosing the device's general configuration (network, hardware, LED setup) to any unauthenticated client on the network. Separately, the settings-PIN unlock state is tracked via a single global boolean `correctPIN` (wled00/wled.h), not per-session state: once any single client submits the correct 4-digit PIN via POST /json, correctPIN becomes true for every client, granting all subsequent unauthenticated clients full configuration-write access (OTA firmware updates, WiFi reconfiguration, factory reset) until the device reboots. |
| Paperless-ngx's MailAccountViewSet.test() action, when called with an existing account's ID and a masked password field, reuses the stored password, account_type, refresh_token, and expiration from that existing account while allowing the caller to supply a different imap_server, imap_port, and imap_security in the same request. The test connection then authenticates to the caller-specified server using the real stored credentials. A user holding only object-level change_mailaccount permission on the target account (not full admin) can redirect the test connection to an attacker-controlled IMAP host, causing the real stored IMAP password or OAuth token to be sent to that host. |
| Grocy's API request-body parser (controllers/Api/BaseApiController.php, GetParsedAndFilteredRequestBody) purifies incoming field values with HTMLPurifier, then manually reverses HTML-entity encoding of the resulting output by replacing &lt;, &gt;, and &amp; back to <, >, and & immediately after purification. This double-decode reconstructs live HTML/script tags from the entity-encoded form that HTMLPurifier produced to neutralize them, re-introducing stored XSS across API-writable fields (products, recipes, stock, users, chores, and others) that are rendered elsewhere without re-sanitization. |
| Miantang/IoT-PHP's index.php implements a POST /userlogin route that reads the password directly from $_POST['pwd'] with no sanitization and concatenates it into a raw SQL string: mysql_query("select * from userlists where username='$username' and password='$password' limit 1"). The username value is passed through htmlspecialchars(), which does not encode single quotes by default and therefore does not prevent SQL injection through the password field. An unauthenticated attacker can submit a payload such as pwd=' OR '1'='1 to bypass authentication and, via UNION-based injection, extract arbitrary data from the database. |
| DjangoCRM ships with its Django SECRET_KEY hardcoded directly in the committed webcrm/settings.py rather than read from an environment variable. Since this key is used for session signing, CSRF token generation, and password reset tokens, anyone who reads the public repository can forge valid session cookies (including for the superadmin account), forge CSRF tokens, and forge password reset tokens, achieving full account takeover. The repository also ships with DEBUG=True as the default, causing error pages to leak database credentials, email credentials, OAuth data, and internal file paths. |
| Firefly III's webhook URL validator (IsValidWebhookUrl.php) filters most private/reserved IPv4 ranges but contains an explicit early-return that allows any resolved address in 127.0.0.0/8, permitting an authenticated user (with webhooks enabled, which is off by default) to configure a webhook targeting loopback services on the server. Additionally, the validator resolves the target hostname once via gethostbyname() at validation time, but the actual outbound request (StandardWebhookSender.php, via Guzzle) re-resolves the hostname independently at send time, allowing a DNS-rebinding attacker to pass validation against a public IP and have the real request delivered to a private or internal address. The webhook response body is only written to a server-side debug log, not returned to the triggering user, so this is a blind SSRF primitive rather than one with direct response read-back. |
| toner-management's admin state-changing handlers (add.php, edit.php, delete.php under admin/toners, admin/toner-brands, admin/printers, and related admin subdirectories) executed INSERT/UPDATE/DELETE database operations with no authentication or authorization check, while access control was enforced only in listing views. An unauthenticated remote attacker could invoke these handlers directly to create, modify, or destroy application data. The vendor has since merged a fix requiring an authenticated admin session before any such handler proceeds. |
| Bolt CMS renders content field values through Twig's full application-level Environment with no SandboxExtension registered anywhere in the codebase. In src/Entity/Field.php, getTwigValue() calls shouldBeRenderedAsTwig(), which gates rendering only on the field definition's allow_twig flag and a regex checking for `{{`, `{%`, or `{#`; when true, the raw field value is compiled and rendered via `self::getTwig()->createTemplate($value)->render(['record' => $this->getContent()])` with no sandboxing. Bolt's own bundled config/bolt/contenttypes.yaml sets `allow_twig: true` on the default "pages" contenttype's content field out of the box. Any user with edit access to that content type (a standard editor role, not just an administrator) can inject a Twig payload such as `{{ ['id']|map('passthru')|join }}` that executes arbitrary OS commands when the content is saved and rendered, achieving remote code execution as the web server user. |
| Mautic's getLeadIdsByFieldValueAction (LeadBundle/Controller/AjaxController.php) reads a field parameter from the request, sanitizes it only with InputHelper::clean() (which HTML-entity-encodes quotes and angle brackets but does not restrict other characters), and passes it into LeadRepository::buildQueryForGetLeadsByFieldValue() where it is concatenated directly as a raw SQL column identifier ($col = 'l.'.$field) rather than being validated against a whitelist of real column names or passed as a bound parameter. Since Doctrine cannot parameterize identifiers, and the sanitizer does not block spaces, parentheses, or other SQL-relevant characters, an attacker can inject SQL via the field name itself. The action requires only a valid session (any authenticated user), unlike sibling actions in the same controller that carry additional permission checks. |
| Documenso's sign-field-with-token.ts, used by the live document-signing UI, allows a recipient with the ASSISTANT role to fetch and complete fields belonging to any later-or-equal-order, not-yet-signed recipient in the same envelope, with no restriction on field type. The handler upserts a Signature record tied to the target field's recipientId with no check that field.type is SIGNATURE and the acting recipient owns it. A newer V2 signing path (sign-envelope-field.ts) explicitly blocks assistants from completing SIGNATURE fields, and the project's own test suite comments confirm this guard is absent from the V1 path used here. In a sequential-signing document, an assistant recipient can therefore forge another signer's signature field. |
| The wp-downloadmanager WordPress plugin, in version 1.68.11 (also affecting the 6.9.4 release line), allows an admin-privileged user (current_user_can('manage_downloads')) to upload arbitrary files via download-add.php with no extension or MIME-type validation of any kind - no wp_check_filetype_and_ext(), no validate_file(), and no extension blocklist exist anywhere in the upload handler. The destination path is additionally built by concatenating the raw, unsanitized $_POST['file_upload_to'] value with no traversal check (no ../ filtering, no basename()/realpath() applied). Since the base download path is required to live under WP_CONTENT_DIR (a web-accessible location), an uploaded PHP file lands in a web-servable path and can be directly executed, resulting in remote code execution. The plugin's own later changelog confirms these protections were absent in this version: v1.69 added file-type validation via wp_check_filetype_and_ext(), and v1.69.1 added directory-traversal protection - neither existed in 1.68.11. |
| The NASA-AMMOS Asynchronous Network Management System (ANMS) reference implementation's default docker-compose.yml publishes the amp-manager service's REST API directly to the host network interface (port 8089, e.g. "${ION_MGR_PORT:-8089}:8089/tcp") with cap_add: NET_ADMIN, NET_RAW, SYS_NICE, bypassing the CAM (Configuration and Access Manager) gateway that is otherwise the system's sole authentication boundary. The underlying REST server, implemented with CivetWeb in JHUAPL/dtnma-tools (src/refdm/nm_rest.c), is configured with enable_auth_domain_check set to "no" and registers every route, including the DTNMA agent command-dispatch endpoints (.../agents/{eid|idx}/send, which accept and forward EXECSET-encoded command sets to a registered DTNMA agent), with a null authentication callback. Any network-reachable client can therefore enumerate registered agents, submit arbitrary command sets to them, and clear stored reports, entirely without credentials. This affects NASA-AMMOS/anms and JHUAPL-DTNMA/dtnma-tools as published; both repositories present this as a reference/ground DTN network-management implementation and testbed, and the affected components communicate with DTNMA agents (which may represent simulated or real spacecraft/ground nodes depending on deployment) rather than being flight software running onboard a spacecraft. |
| The render-template component of ember-dynamic-render-template (addon/components/render-template.js) passes its `templateString` property directly into Ember/Glimmer's compileTemplate() (from @ember/template-compilation) with no sanitization, allow-listing, or validation of the input. Because compileTemplate() dynamically compiles and renders the supplied string as a live Handlebars/Glimmer template, any application that renders attacker-influenced data through this component's templateString property is exposed to client-side template injection: an attacker-controlled Handlebars expression is compiled and executed in the context of the rendering component, which can be leveraged for cross-site scripting depending on what helpers/context are exposed to the compiled template. |
| Fledge's backup-restore upload handler, upload_backup() (python/fledge/services/core/api/backup_restore.py), takes the first extracted tar member's filename (tar_file_names[0]) and builds a shell command via string formatting: `cmd = "cp {} {}".format(source, backup_path); ret_code = os.system(cmd)`. The only pre-check on the filename is a prefix/suffix match (startswith(backup_prefix), endswith(valid_extensions)), which a name such as `fledge_backup_$(id>/tmp/pwn).db` satisfies while still injecting a shell command substitution. Because os.system() invokes a shell and no quoting (shlex.quote, list-form subprocess) is applied, an admin uploading a crafted backup archive achieves arbitrary OS command execution. |
| Zigbee2MQTT's ExternalJSExtension.getFilePath() (lib/extension/externalJS.ts) joins a `name` parameter received via an MQTT message (topic zigbee2mqtt/bridge/request/extension/save) into the extensions base path using path.join(basePath, name) with no sanitization. Because path.join() resolves `../` sequences, a name such as `../../tmp/evil.js` escapes the intended extensions directory. The extension handler only validates that the name ends in .js/.mjs/.cjs, writes the file, and then dynamically imports it via Node.js import(), achieving remote code execution. Requires the `enable_external_js` config option (off by default, but commonly enabled in legacy installs) and MQTT broker access, which is frequently unauthenticated in real deployments. The identical unsanitized getFilePath() is also used by the extension-removal handler, enabling arbitrary file deletion. |
| rust-iot-platform allows creating a "calc rule" via POST /calc-rule/create (api/src/controller/calc_rule_router.rs) containing an arbitrary `script` field. This route does not take the AuthToken request guard used elsewhere in the application, making it reachable without authentication. The stored script is subsequently executed via quick_js::Context::eval() in api/src/biz/calc_run_biz.rs with no sandboxing, allowing an unauthenticated attacker to achieve arbitrary JavaScript execution in the server process by creating and triggering a malicious calc rule. |
| rust-iot-platform's AuthToken request-guard implementation (api/src/main.rs) only checks whether the Authorization HTTP header is present, and never validates its value against any session, token store, or signature. Any request carrying an arbitrary non-empty Authorization header (e.g. `Authorization: fake`) satisfies the guard, granting access to every endpoint protected only by this request guard. |
| Magistrala (formerly Mainflux)'s message-readers API reads a `format` value from the HTTP query string (readers/api/http/transport.go) with no validation and interpolates it directly into raw SQL queries via fmt.Sprintf() in both the PostgreSQL reader (readers/postgres/messages.go: `fmt.Sprintf("SELECT * FROM %s WHERE %s ...", format, cond)`) and the TimescaleDB reader (readers/timescale/messages.go, same pattern), enabling SQL injection by any authenticated user able to query channel messages. |
| OpenBK7231T's http_fn_ota_exec() (src/httpserver/http_fns.c) reflects the `host` query parameter directly into an HTML response via hprintf255(request, "<h3>OTA requested for %s!</h3>", tmpA) with no HTML encoding, allowing a crafted URL such as /ota_exec?host=<script>alert(1)</script> to execute JavaScript in an authenticated admin's browser when they click a malicious link. |
| Stirling-PDF's POST /api/v1/convert/url/pdf endpoint (ConvertWebsiteToPDF.java) was not updated with the CustomHtmlSanitizer/SsrfProtectionService SSRF protections that were added to three sibling conversion endpoints (html/pdf, file/pdf, markdown/pdf). The endpoint validates only that the initial requested URL resolves to a public IP, then fetches the page's HTML server-side and hands it, unsanitized, to a WeasyPrint subprocess. Embedded resource references in the fetched HTML (e.g. `<img src="http://169.254.169.254/...">`) are fetched by WeasyPrint with no per-resource SSRF filtering, allowing an attacker-controlled page to cause the server to retrieve cloud metadata endpoints or internal network resources and leak their contents back into the generated PDF. |
