Stored cross-site scripting in the PowerPress Podcasting plugin by Blubrry for WordPress before 11.17.2 lets an authenticated user with contributor-level access or higher inject a script payload into an unsanitized block attribute, which then executes in the browser session of any higher-privileged user (editor or administrator) who views the rendered page. Exploitation is not anonymous: it requires a valid low-privilege account, the ability to add or edit a PowerPress block, and victim interaction with the poisoned content, which is why the vendor's 6.8 score is assessed as generous on both privilege required and scope. Publicly available exploit code exists and WPScan has published a proof-of-concept advisory, but EPSS is only 0.15% (4th percentile) and there is no signal of active exploitation, so this is best treated as a moderate-risk, patch-now issue for sites that grant contributor accounts.
Stored cross-site scripting in the Optima Express IDX WordPress plugin before 8.7.6 allows an authenticated user with a role as low as author to inject a script value through one of the plugin's REST endpoints, which is persisted and then echoed unfiltered into the document head whenever the affected post is rendered. Exploitation requires a valid low-privileged WordPress account and completes only when a victim (for example an administrator or site visitor) loads the poisoned post in a browser, making it a stored, persistent injection rather than a reflected one. Publicly available exploit code exists and the issue is listed in WPScan with an advisory, but there is no confirmed active exploitation (CISA KEV absent, SSVC exploitation: none) and EPSS is low at 0.15% (4th percentile), so it should be treated as a genuine but modest-priority patch-now issue. A vendor fix is available in 8.7.6.
Stored cross-site scripting in the WP YouTube Lyte WordPress plugin before 1.7.31 allows an authenticated user with only contributor-level access to inject script via YouTube embed block attributes that are rendered into HTML without escaping. The payload does not fire on its own: a higher-privileged user such as an editor or administrator must subsequently view or render the poisoned block for the stored script to execute, so realistic exposure is limited to sites that grant contributor-or-higher accounts to semi-trusted users and that review contributor content. Publicly available exploit code exists, but EPSS is low at 0.15% (4th percentile), there is no CISA KEV listing, SSVC records no observed exploitation, and an independent assessment rates the practical risk as a high-scoring-but-modest-real-impact stored XSS rather than a mass-exploitable bug. Note the vendor-reported vector (6.8, PR:H) is more conservative than the independently assessed vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N), which considers the contributor-level prerequisite and the required user interaction.
Stored cross-site scripting in the WPeMatico RSS Feed Fetcher WordPress plugin before 2.8.27 lets an authenticated user with the Contributor role or higher inject a script payload into content pulled from an attacker-influenced RSS feed, which the plugin then saves as post content without sanitization; the payload executes when a victim renders the affected post. Exploitation is not automatic and requires the victim to view the poisoned post, so it is a genuine but low-urgency issue, reinforced by a very low EPSS score of 0.15% (4th percentile) and no indication of active exploitation in CISA KEV or the SSVC assessment (Exploitation: none, Automatable: no) - although publicly available exploit code does exist. Only sites running versions prior to 2.8.27 with low-privilege Contributor-level accounts are affected.
Stored cross-site scripting in the EmbedPress WordPress plugin before 4.6.7 allows an authenticated attacker holding at least the Contributor role to inject a payload through one of the plugin's block attributes, which is written into an HTML attribute without escaping and executes in the browser of a higher-privileged user (Editor or Administrator) who views or previews the compromised post. Exploitation is not autonomous - it requires an existing low-privilege account plus victim user interaction - and the independent assessment rates it as a plausible but low-priority issue; EPSS is 0.15% (4th percentile), CISA SSVC records no exploitation and no automatable path, and there is no KEV listing, although publicly available exploit code exists. A vendor fix is available in EmbedPress 4.6.7.
Authorization bypass in NextScripts SNAP (Social Networks Auto-Poster) before 4.4.8 allows an authenticated WordPress user who has been granted access to SNAP's posting features to export configured social account credentials, delete arbitrary posts, and reset the plugin configuration. The AJAX actions lack capability and ownership checks and rely on a nonce, which can be obtained from the plugin interface, so no administrator role is needed once posting access exists. Publicly available exploit code exists; EPSS is low at 0.13% (2nd percentile), there is no CISA KEV listing, and a vendor fix is available in 4.4.8.
Missing authentication in Coolify's GitHub App setup handler (Github::redirect at /webhooks/source/github/redirect) in versions up to and including 4.1.0 allows unauthenticated remote attackers to supply a crafted 'state' value matching an existing GitHub App UUID and cause the application to run the GitHub App manifest conversion flow, overwriting that App's stored client ID, client secret, webhook secret and private key. Publicly available exploit code exists, but exploitation is gated on knowing a valid - typically mid-setup - GitHub App UUID, which the independent assessment treats as raising attack complexity above the vendor's AC:L rating (CVSS:3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N), making this a genuine but moderate-severity credential-overwrite issue rather than a trivially mass-exploitable bypass. No CISA KEV entry or confirmed in-the-wild activity has been reported; the CVE is currently associated only with published proof-of-concept material against the affected endpoint.
Missing authorization in Coolify up to and including 4.1.2 allows remote attackers to perform resource-update operations they are not entitled to, because the CanUpdateResource route-level middleware was shipped with its entire authorization body - the Gate::allows('update', $resource) check and the surrounding resource-resolution logic - commented out, turning it into a no-op pass-through. Any multi-user or multi-team Coolify deployment on 4.1.2 or earlier is exposed across application, database, service, server, environment and project update routes; the vendor's CVSS 4.0 vector rates the flaw PR:N while the assessed CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L) indicates a valid authenticated Coolify account is realistically required, since the affected routes sit behind login. Publicly available exploit code exists and upgrading to 4.2.0 fixes the issue; there is no CISA KEV listing, so this is not confirmed active exploitation.
Unauthenticated remote users can still reach the installer and admin-config-setup endpoints of Krayin CRM (laravel-crm) 2.2.4 and earlier because the CanInstall middleware and InstallerController never abort once the application has already been installed, an authorization bypass that allows installer functionality to be re-driven on a live instance. Publicly available exploit code exists (a published advisory demonstrating an unauthenticated installer bypass), though there is no confirmed active exploitation (not in CISA KEV); the assessed vector is network-reachable, no privileges, no user interaction, with low confidentiality, integrity, and availability impact. Only self-hosted deployments left network-reachable with the Installer package present are exposed, and the vendor has released a patched version.
Out-of-bounds write in Trusted Domain Project OpenDKIM through 2.11.0 allows remote, unauthenticated attackers to corrupt memory by sending a crafted DKIM-Signature header whose h= signed-headers tag is manipulated before it reaches dkim_canon_selecthdrs during canonicalization. The practical impact is expected to be a milter crash or mail-flow denial of service, with confirmed memory corruption rather than proven code execution, and the independent assessment maps it to CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L while the supplied CVSS 4.0 vector is AV:N/AC:L/AT:N/PR:N/UI:N. Publicly available exploit code exists for this issue, and no vendor-released patch was identified at time of analysis; the vendor was contacted and reportedly did not respond.
SQL injection in the addnewstudent.php endpoint of mathurvishal's CloudClassroom-PHP-Project lets remote attackers inject arbitrary SQL via user-supplied input, with the disclosed vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N, base 6.9) and our assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N both indicating no authentication barrier and a high confidentiality impact, with integrity loss limited to portions of the database reachable by the application's DB account. Publicly available exploit code exists: a proof-of-concept write-up was published on GitHub (vinniboy021-blip/Advisory, addnewstudent-sqli.md) complementing the VulDB entry, so the skill needed to weaponize the flaw is low, although there is no CISA KEV entry confirming active exploitation and no EPSS score was supplied. Practical exposure is heavily constrained because this is an unversioned, hobby-grade PHP project with no packaged releases, an unresponsive vendor, and an addnewstudent endpoint that in a real deployment may sit behind an administrative login even though the vector claims PR:N.
Unauthenticated local file inclusion in the WebFacing WordPress plugin before 5.4 lets any remote visitor reach a bundled script that the plugin fails to access-restrict and pass a user-supplied path into a local file include, exposing files readable by the web-server user such as wp-config.php. Exploitation requires no authentication, no user interaction, and no non-default configuration (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U), and publicly available exploit code exists, though CISA KEV does not list this CVE as actively exploited and EPSS remains low at 0.31% (21st percentile). WPScan and the vendor rate confidentiality impact as Low (5.3), while our independent assessment rates it High (C:H) because the contents of readable configuration files can be immediately leveraged against the site.
Unauthenticated information disclosure in the Mailchimp for WooCommerce WordPress plugin before version 6.3 allows anyone who already knows a customer's email address to retrieve that customer's saved cart contents and confirm that the individual shops at the store. The saved-cart endpoint trusts a request-supplied identifier derived from the customer's email without requiring authentication or verifying ownership, so the attack is remote, needs no credentials and no user interaction, but is limited to read-only disclosure of cart data for accounts whose email the attacker already possesses. Vendor-released patch is available (version 6.3), publicly available exploit code exists, and exploitation has not been confirmed as active (CISA KEV not listed); EPSS is 0.18% (6th percentile), consistent with a low-severity, targeted-reconnaissance issue rather than a mass-exploited one.
Unauthenticated attackers can retrieve digital-goods files attached to arbitrary orders through the Verge3D Publishing and E-Commerce WordPress plugin (through version 4.13.0) because its file-download handler performs no access control. CVSS 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N) reflects a bounded confidentiality impact, and EPSS is 0.14% (3rd percentile); publicly available exploit code exists, but the vulnerability is not in CISA KEV and SSVC records exploitation as none. The exposure is confined to the digital-goods files themselves - not site credentials, admin functions, or the wider database.
Credential disclosure in the UpdraftPlus WordPress backup and migration plugin lets any authenticated user - including a low-privileged subscriber - read the passwords and secret keys of the site's configured remote backup destinations, but only while the site is left in a specific post-migration state. Affected releases are the 1.x branch from 1.23.8 up to (but not including) 1.26.8 and the 2.x branch from 2.23.8 up to (but not including) 2.26.8.26; both branches are fixed in 1.26.8 and 2.26.8.26. Publicly available exploit code exists via the WPScan entry, but EPSS is low at 0.14% (roughly 3rd percentile) and the CISA SSVC assessment records no observed exploitation, so exploitation depends on a site actually being in the vulnerable post-migration state.
Unauthenticated remote attackers can force the creation of a fixed author-role WordPress account - and repeatedly rotate that account's application password - on any site running the Optima Express IDX plugin from 8.5.0 up to (but not including) 8.7.6, because one of its AJAX actions lacks any authorization check and is exposed to logged-out users. Exploitation requires no authentication (PR:N), no user interaction (UI:N), and low complexity; publicly available exploit code exists, though CISA's SSVC records no observed exploitation and EPSS is low at 0.14% (3rd percentile). Impact is bounded: the forged account is an author, not an administrator, so the flaw yields low-level integrity and confidentiality effects rather than full site takeover.
Authenticated contributors can bypass publishing permissions and spoof post authorship in WordPress sites running WPeMatico RSS Feed Fetcher before 2.8.27. By running a feed campaign, a user with contributor-level access or above can publish posts live without editorial review and set any registered user, including an administrator, as the author. Publicly available exploit code exists, but no active exploitation has been reported, and the EPSS score is low at 0.13% (percentile 2%). The independent assessment rates this as a moderate-severity, low-priority authorization flaw.
Authenticated users who hold a specifically delegated booking-management capability in the Online Scheduling and Appointment Booking System WordPress plugin (versions 23.2 through 28.3) can chain an unsafe PHP deserialization flaw with a broken access control check on a privileged maintenance routine to inject arbitrary PHP objects, overwrite privileged site options, and read stored integration secrets. The plugin does not restrict that maintenance feature to administrators and does not prevent deserialization of untrusted input, so any account granted this custom capability - which an administrator must explicitly assign, a non-default delegated privilege - can reach the vulnerable path; no end-user interaction is required (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:L, score 4.7). Publicly available exploit code exists, but there is no confirmed active exploitation (the issue is not in CISA KEV) and EPSS is only 0.15% (4th percentile), so signals converge on a genuine-but-low real-world priority.
Server-side request forgery in the WPeMatico RSS Feed Fetcher WordPress plugin before 2.8.27 lets an authenticated user holding contributor-level access or higher supply an arbitrary URL through the plugin's feed-fetch feature, causing the web server to request that URL and return the response body back to the requester; the plugin performs no capability check on that action. Because the request originates from the server, the attacker can reach internal-only or loopback services that are otherwise unreachable from the internet - most notably cloud instance metadata endpoints and internal administrative interfaces - but the impact is limited to confidentiality, since no code execution or write capability is demonstrated. Publicly available exploit code exists (the WPScan entry documents the issue), CISA KEV does not list the CVE, and EPSS is 0.13% (2nd percentile), indicating low near-term exploitation likelihood; the assessed severity is low-to-moderate, contingent on the site allowing low-trust contributor registrations and on which internal services are reachable from the web server.
Server-side request forgery in the WPeMatico RSS Feed Fetcher WordPress plugin before version 2.8.27 allows an authenticated attacker holding contributor-level access or higher to direct the web server to fetch an arbitrary attacker-supplied feed URL and read the response back, enabling internal-only reconnaissance and retrieval of sensitive data such as cloud instance metadata. The plugin performs neither a capability check nor any validation of the destination before issuing the server-side request, and because the retrieval is non-blind the attacker receives the fetched content rather than learning only success or failure. Exploitation is constrained by the contributor-role prerequisite and by read-only impact (no write, no code execution), and public exploit code exists via the WPScan disclosure while EPSS remains very low at 0.13% (2nd percentile) and CISA's SSVC assessment records exploitation as none; this is a genuine but low-priority issue.
Information disclosure and cross-boundary host memory corruption in vm2 before 3.12.2 let untrusted guest JavaScript read and modify bytes outside the sandbox whenever the embedding application explicitly allowlists Node's zlib builtin via require: { builtin: ['zlib'] }. vm2 fails to apply its Buffer backing-store ownership invariant (byteOffset === 0 && buffer.byteLength === length) to Buffers returned from host builtin modules, so zlib.deflateSync can hand back a pooled buffer whose .buffer getter exposes Node's entire 64 KiB shared small-buffer pool; a guest then builds a full-width view with Buffer.from(result.buffer, 0, result.buffer.byteLength) to disclose secrets (session tokens, decrypted material, DB rows) and corrupt unrelated host buffers sharing that pool. This is not reachable in a default vm2 deployment - it requires a non-default zlib allowlist, attacker-controlled script execution, and host secrets co-resident in the pool at exploitation time - and no public exploit code was identified at time of analysis; the vendor rates it CVSS 4.0 6.9 (Medium) with a vendor-released patch in 3.12.2.
Unauthenticated download of in-house iOS application packages and manifests is possible against enterprise-tier Fleet deployments running versions before 4.87.0, because two sessionless MDM endpoints were shipped without the intended random, time-limited URL token, letting anyone with network reach to the Fleet server fetch IPA binaries and their metadata (bundle identifier, version, name) by guessing sequential title identifiers. Impact is confined to read-only information disclosure - there is no privilege escalation or write access, the free tier is unaffected (it returns fleet.ErrMissingLicense), and hosts not managed by Fleet are untouched. The vendor CVSS 4.0 score is 6.9 (MEDIUM) while our independently assessed CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N; no public exploit code or confirmed active exploitation was identified at time of analysis.
Revoked, expired, or download-limit-exhausted Cloudreve shares can still be mined for signed file URLs for up to 300 seconds because the file/url and file/thumb routes trust a client-supplied context_hint UUID and restore cached share navigator state without re-running the share validity or password checks (CWE-863, incorrectly cached authorization). All Cloudreve releases before 4.16.1 are affected; the independent assessment rates this moderate (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N), with remote attackers (CVSS PR:N) needing prior valid access to the share, knowledge of the target file URI from an earlier listing, and a pre-warmed hint, so this is a revocation/expiry bypass for already-known content rather than a way to discover unknown share contents. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and a vendor patch is available.
Cleartext storage and over-exposure of multiple capability secrets in Heym, a workflow automation platform, affects all versions prior to 0.0.91 and allows anyone with read access to a workflow, share/team membership, or read access to the database, a backup, or logs to recover and replay those secrets to execute workflows or act as the secret owner. Exposed values include webhook header-auth credentials returned in cleartext by GET /api/workflows/{id} and persisted into execution history, MCP API keys stored as a plaintext column and accepted via a ?key= query string that leaks into logs, proxies, and Referer headers, portal session tokens validated by plaintext equality with a 168-hour TTL, workflow execution JWTs re-listed by GET .../execution-tokens, Discord interaction tokens, and global variables. The vendor CVSS 4.0 score is 6.9 (medium) with a high-privilege prerequisite (PR:H), our independent assessment scores it CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, exploitation is bounded by the need for prior authorized read access rather than a special configuration, a vendor patch is available in 0.0.91, and no public exploit was identified at time of analysis.
Cross-site request forgery in the Event Gallery extension for Joomla (svenbluege.de) affects versions below 6.5.0 and lets an attacker craft a malicious web page that silently performs shopping-cart actions on behalf of a logged-in site user, because those cart endpoints do not validate an anti-CSRF token. Exploitation requires the victim to be authenticated to a Joomla site running the vulnerable extension and to visit attacker-controlled content while that session is active; impact is limited to integrity (manipulation of cart state) with no confidentiality or availability loss, consistent with the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/C:N/I:L/A:N) rather than a worst-case reading of the vendor's 6.9 base score. No public exploit code or active exploitation has been reported, and the vendor has released version 6.5.0 as the fixed release.
Malicious Kubernetes hosts can read confidential data written to Contrast secure persistent volumes by supplying a crafted LUKS2 block device that the pod VM wrongly accepts as encrypted. The flaw affects Contrast (Go module github.com/edgelesssys/contrast) through 1.12.0 when the opt-in secure persistent volume feature is enabled and the guest bundles cryptsetup older than 2.8.1: LUKS2 metadata is unauthenticated and a header declaring the cipher_null-ecb null keyslot algorithm is accepted without error, so the Initializer assumes the device is protected when 'cryptsetup open' succeeds and writes secrets to a volume that is plaintext or keyed with an attacker-known volume key. Exploitation requires host-level provisioning privilege (CVSS 4.0 AV:A/AC:L/PR:L/UI:N, confidentiality-only; independent assessment CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), meaning the adversary is a malicious or compromised infrastructure operator rather than a conventional remote attacker; there is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV), and the issue is closed by Contrast 1.12.1, which ships cryptsetup 2.8.1, and further hardened by 1.13.0.
Unauthenticated disclosure of MCP Registry metadata affects Obot deployments running versions up to and including v0.22.1 when the operator has enabled registry authentication via OBOT_SERVER_ENABLE_REGISTRY_AUTH=true. A single unauthenticated GET request to /v0.1/servers returns 200 OK and exposes the registry inventory - server names, descriptions, repository URLs, icons, and connect URLs - that the operator explicitly intended to place behind authentication, because the authorizer's default-allow logic never matched the registry's top-level /v0.1 prefix. No public exploit code has been identified at time of analysis, and the independent assessment rates this as a low-impact, high-confidence information-disclosure flaw (CVSS v3.1 5.3) rather than the CVSS v4.0 6.9 figure in the CVE record: the per-user ACR filter still limits anonymous callers to entries visible to the anonymous identity, no secret environment or header values are exposed, and connecting to listed servers remains properly auth-protected.
heym before 0.0.105 fails to enforce credential authorization in its Redis workflow node, letting an authenticated workflow author cause the node to fall back to unauthenticated defaults on the backend's loopback interface. When the credential lookup returns no accessible credential - because the ID does not exist, was deleted, or belongs to another user - the node treats the failure as empty configuration and connects to localhost:6379 with no password, executing the requested Redis operation there. The impact is deployment-gated: the stock docker-compose.yml ships no Redis, so default installs only surface a misleading connection error, while operators who have placed a passwordless Redis on loopback face unauthorized read/write access; no public exploit has been identified at time of analysis and no EPSS or KEV signal is available.
Host-header routing bypass in http4k (Maven artifact org.http4k:http4k-core) before 6.49.0.0, 5.42.0.0 and 4.51.0.0 lets remote, unauthenticated attackers reach a virtual host they should not be authorized for by supplying a Host header that merely contains a configured vhost name - for example Host: admin.evil.com against a vhost configured as "admin" - because reverseProxy() and reverseProxyRouting() default to a substring (Contains) matcher rather than an exact match. Exploitation is tightly scoped: it requires the functions to be deployed as a public-facing inbound HTTP handler with two or more configured virtual hosts, where that routing is what enforces authorization; the documented outbound-dispatch and test-time fake-backend uses set the Host value from the calling application and are unaffected. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the issue is a genuine but narrow authorization-bypass rather than a high-severity emergency; vendor patches are available in 6.49.0.0 (Community 6.x), 5.42.0.0 and 4.51.0.0 (Enterprise LTS lines).
Time-of-check-to-time-of-use race condition in the account recovery endpoint of vulnerability-lookup (/user/confirm_account/<token>) allows two concurrent HTTP requests carrying the same valid single-use recovery token to both pass the nonce verification step before either transaction commits, so both callers set a password on the target account and the last commit wins. The same view also accepted empty or trivially short (three-character) passwords because it compared the two password fields manually instead of invoking the form's validation logic, bypassing the intended minimum-length and complexity constraints. No public exploit code has been identified at time of analysis, and although the requests are unauthenticated over the network (CVSS:4.0 PR:N), exploitation is gated by the hard prerequisite that the attacker already possesses a live, unconsumed recovery token for the target account plus the timing precision needed to win the race window - a combination the independent assessment captures in its CVSS:3.1 vector AV:N/AC:H/PR:N/UI:N/C:L/I:L/A:N, keeping real-world risk moderate rather than critical.
Certificate name-constraint enforcement can be bypassed in wolfSSL 5.9.2 and earlier, allowing a certificate to be accepted for hostnames it is not authorized to cover. The X.509 path-validation state machine loses track of NameConstraints when an intermediate CA without a NameConstraints extension sits between a name-constrained CA and the leaf, so the effective trust delegation is not enforced; exploitation requires a PKI topology with exactly that chain shape and a relying party that uses name constraints in its default build. No public exploit code has been identified at time of analysis, and the attacker must already be able to obtain a leaf certificate chaining up through the unconstrained subordinate tier, which keeps real-world leverage conditional and complexity high.
wolfSSL 5.9.2 accepts leaf certificates whose Subject CN falls outside a CA's dNSName name constraints whenever the leaf carries any other SAN type (such as registeredID or iPAddress) instead of a dNSName SAN, allowing an out-of-scope identity to pass validation. The defect is a regression introduced by the incomplete fix for CVE-2026-6731: the CN-as-DNS fallback was gated on the absence of any SAN extension rather than the absence of a dNSName SAN specifically. Exploitation is unauthenticated and remote per the CVSS vector (PR:N, AV:N, AC:H), but requires an uncommon PKI configuration where the issuing CA enforces dNSName name constraints; there is no public exploit identified at time of analysis and impact is limited to Low confidentiality and integrity with no availability effect.
Credential leakage in Edgeless Systems Contrast through 1.20.0 stems from unanchored suffix matching in the imagepuller's per-registry configuration lookup, which allows a registry block defined for one FQDN to be applied to any hostname merely ending in that same byte sequence. When a deployment pulls an image from a sibling domain such as evilghcr.io that an attacker has registered (or that appears coincidentally in the pull path), the imagepuller transmits the configured Authorization header - basic auth, registry token, or identity token - and additionally inherits the host's custom CA bundle, mirror setting, and insecure-skip-verify behavior, disabling TLS verification for that host. The CVSS 4.0 base score is 6.3 (our independent assessment scores it 3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N), and the vector requires no privileges (PR:N) but is rated high-complexity because two independent preconditions must align: a per-registry FQDN configured without a leading dot, and an image pulled from a matching suffix domain. There is no public exploit identified at time of analysis and no KEV listing; the issue is best treated as configuration hygiene, and configuration entries that use a leading dot (for example [registries.".example.registry"]) are entirely unaffected.
Certificate-validation bypass in wolfSSL 5.8.4 through 5.9.2 lets an attacker-supplied CA become permanently trusted: a first, deliberately failed wolfSSL_X509_verify_cert call leaves the attacker's intermediate/root cached in the process-wide CertManager, so a later on-path attacker presenting a chain rooted at that planted CA is accepted by any type-blind consumer of the shared store (native TLS, OCSP, CRL, direct CM verification). The bug is reachable by unauthenticated remote attackers (CVSS PR:N/AV:N) but is heavily constrained: it requires a non-default build (OPENSSL_EXTRA && !NO_CERTS && !WOLFCRYPT_ONLY, i.e. --enable-opensslextra), an application that actually calls the X509_verify_cert compatibility API, and the AC:H/AT:P precondition that a prior verification failure was induced, so applications relying on stapling or native wolfSSL verification are unaffected. No public exploit code or confirmed active exploitation has been identified at time of analysis; the upstream fix is in GitHub PR 11009, with the released patched version not independently confirmed.
wolfSSL (D)TLS 1.2 clients can be tricked into accepting attacker-controlled application data as authentic: when a ChangeCipherSpec record arrives before the client has sent its ClientKeyExchange, no master secret has been derived, so the client installs read keys built from deterministic (all-zero) key material and then validates the attacker's Finished message against those same keys. DTLS 1.2 clients are exposed in their default configuration because a single datagram read can deliver the out-of-order records on its own, while TLS 1.2 clients are exposed only when the application feeds received bytes through wolfSSL_inject() or enables read-ahead; for certificate-based suites the attacker must additionally hold an on-path man-in-the-middle position, whereas for PSK suites any rogue server succeeds without knowing the pre-shared key. The client's own outbound traffic remains protected by correctly derived keys, the genuine server never completes the handshake, and no public exploit code or CISA KEV entry was identified at time of analysis.
Denial of service in Nezha, the server and website monitoring tool, affects versions 2.2.11 through 2.3.0, where an authenticated user holding the member role and owning at least one agent can crash the entire instance. The attacker issues a concurrent server-delete request (POST /api/v1/batch-delete/server) against their own server to win a narrow TOCTOU race inside the sentinel worker, which then dereferences a missing entry in its server-list snapshot; because the sentinel workers and the gRPC server lack any recover()/recovery interceptor, the resulting panic is unrecovered and brings down the whole process. This is an availability-only flaw (no confidentiality or integrity impact) rated 6.0 under CVSS 4.0 and 5.9 (AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) in our independent assessment, with no public exploit code identified at time of analysis and a fix available in 2.3.1.
SQL injection in the CloudClassroom PHP Project (rolling-release codebase, affected through commit 5dadec098bfbbf3300d60c3494db3fb95b66e7be) allows remote attackers to manipulate the myfid parameter of updatedetailsfromfaculty.php and execute attacker-controlled SQL. Publicly available exploit code exists, and the independent assessment rates the flaw as high confidentiality impact with low integrity impact under CVSS 3.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N), while noting the endpoint name suggests a faculty session may normally be required. The vendor was contacted but did not respond, and no fixed release exists because the project is rolling-release, so deployments tracking the referenced commit or earlier remain exposed.
Authenticated users of the Nezha monitoring dashboard (versions 2.0.10 through 2.3.2) who can configure notification or DDNS webhook URLs can bypass the dashboard's SSRF denylist by supplying an IPv6 literal in the 6to4 prefix 2002::/16 or the local-use NAT64 prefix 64:ff9b:1::/48, causing the server to issue outbound HTTP requests to those endpoints. Exploitation is heavily constrained: the CVSS vector is PR:L, meaning an attacker must already hold a webhook-configuring account, and meaningful impact depends on the deployment's network providing unusual or non-standards-compliant routing for these transition ranges; the advisory confirms no path to IPv4 metadata, loopback, or private-network requests was demonstrated. No public exploit code has been identified at time of analysis and the issue is not known to be exploited, but the vendor has shipped a fix in version 2.3.3 (commit d1fcde8e) that explicitly blocks both prefixes. The independent assessment rates this as a low-priority, high-caveat SSRF with AC:H and only low confidentiality impact.
Unauthenticated WebSocket access in the Penpot MCP server plugin's browser bridge (PluginBridge) lets attackers on adjacent networks impersonate the Penpot browser plugin, intercept MCP task payloads, and return forged results when Penpot runs in single-user mode. Affected versions are before 2.18.0, and exploitation requires local network reachability to the exposed WebSocket port, with impact capped at plugin impersonation and confidentiality/integrity loss (CVSS 5.3) rather than code execution. No public exploit code or CISA KEV listing was identified at time of analysis, and the separate ReplServer /execute RCE (GHSA-22qr) is an unrelated defect with different prerequisites.
Server-side request forgery in Heym 0.0.90 and earlier lets a caller-controlled workflow input steer an outbound HTTP fetch to loopback, RFC1918, link-local, or cloud metadata endpoints such as 169.254.169.254. Two distinct egress gaps exist: the LLM image-edit loader (_load_image_bytes) issues a bare httpx.get that skips the egress-pinning client, and _is_public_address only unwraps IPv4-mapped IPv6, so NAT64 (64:ff9b::/96), IPv4-compatible (::x.x.x.x), and 6to4 (2002::/16) encodings can smuggle internal IPv4 destinations past both URL validation and the dial-time IP pin. Exploitation is not automatic: an authenticated workflow author must have deliberately wired a caller-controlled expression such as "imageInput": "$userInput.body.imageUrl" before an unauthenticated webhook or API caller can pick the target, and this is best treated as a low-to-medium priority SSRF issue; no public exploit code was identified at time of analysis. The second, IPv6-based gap additionally depends on the Python 3.11.0 through 3.11.9 behavior that classifies 6to4 as globally routable.
Reflected cross-site scripting and open redirect in Event Gallery for Joomla before 6.5.0 allow unauthenticated remote attackers to redirect victims or execute script in their browser if they click a crafted link containing a base64-encoded 'return' parameter. The extension decodes that parameter and writes it into the 'Back' link without validation, but exploitation requires user interaction and the vulnerable extension must be installed. No public exploit identified at time of analysis; the issue is assessed as moderate and low priority with client-side impact only.
KitchenOwl through 0.7.10 allows authenticated users to read category metadata (names, budgets, and colors) from other households due to a broken object-level authorization flaw in the expense and item API operations. The vulnerability requires a valid account and targets the addExpense/updateExpense and addItem/updateItem endpoints, which fail to verify that a supplied category ID belongs to the caller's household. No public exploit code has been identified at time of analysis, and the impact is limited to read-only information disclosure in multi-household deployments.
Cloudreve before 4.17.0 applies only the Admin.Read OAuth scope to the admin node test endpoints (POST /api/v4/admin/node/test and POST /api/v4/admin/node/test/downloader), while the sibling node create, update, and delete routes correctly demand Admin.Write. An authenticated holder of an admin-authorized OAuth token carrying only Admin.Read can therefore submit crafted node definitions and force the Cloudreve server to make outbound requests to arbitrary URLs, yielding blind server-side request forgery, internal service probing, and delivery of signed Cloudreve slave-style requests to attacker-chosen hosts; because the responses are not returned to the caller, impact is limited to blind SSRF and availability-adjacent network effects rather than direct data disclosure. No public exploit code was identified at time of analysis, exploitation is not confirmed in CISA KEV, and the practical prerequisite is an environment where an administrator has granted an OAuth client the Admin.Read scope - a real but bounded prerequisite that is consistent with the medium (5.3) severity rating and the authenticated (PR:L) nature of the flaw. The vendor has released a patch in 4.17.0 and upstream fix commit 332a9d800205082a2469e555fd66a63f18d9d5dc.
SSRF protections can be bypassed in heym before 0.0.105 by authenticated users who configure integration service credentials with base URLs pointing to internal or cloud-metadata addresses, enabling them to read internal service responses through workflow node output. This moderate-severity issue requires low-privileged authentication and has no public exploit identified at time of analysis.
AzuraCast 0.23.5 and earlier exposes its internal Liquidsoap API endpoint (/api/internal/{station_id}/liquidsoap/{action}) to the public web interface, allowing any authenticated user who holds only the basic View station permission to invoke privileged Liquidsoap commands. The endpoint is missing the RequireInternalConnection middleware that guards the sibling /sftp-auth and /sftp-event routes, and the $asAutoDj flag is derived from the mere presence of the X-Liquidsoap-Api-Key header rather than its validated value, so the header value is never checked when the ACL check passes. Practical impact is bounded to spoofed now-playing metadata visible to all listeners, disruption of live broadcast tracking, and disclosure of absolute filesystem paths (assessed CVSS:3.1 5.3, C:L/I:L/A:L) - a genuine but moderate CWE-862 access-control flaw, most relevant to multi-tenant installations where untrusted users hold station accounts. A vendor fix is available in 0.23.6; no public exploit code has been identified at time of analysis.
Authenticated workloads that hold a valid mesh certificate can force a recovered runtime panic in the Edgeless Contrast Coordinator's transit-engine endpoint (all versions through 1.20.0) by submitting a 'vault:vX:base64' ciphertext whose third component decodes to fewer than 12 bytes. The panic is caught by net/http and returned as a 500, so the process survives, but each trigger aborts the request mid-handler and writes the recovered panic to the Coordinator logs, producing log spam, request-failure metrics, and a cheap, low-rate degradation of the transit-engine API. Reachability is gated by mesh-certificate authentication (CVSS 4.0 base 5.3, AV:N/PR:L, availability-only), and no public exploit code or confirmed active exploitation was identified at time of analysis; a vendor fix is available in 1.21.0, making this a low-priority hardening item rather than an urgent one.
Contrast versions up to and including 1.9.0 allow the untrusted host underlying a bare-metal confidential container deployment to write arbitrary file trees below a container's VOLUME mount point, compromising the integrity of a directory that is typically central to the application's core functionality. The weakness occurs because containerd auto-creates a mount point for any OCI config.volumes entry that Kubernetes does not explicitly mount, forcing the runtime to relay host-supplied content to the Kata agent; only integrity of that path is affected, with no confidentiality or availability impact. It is rated low severity (CVSS 4.0 5.1; assessed CVSS 3.1 AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N), affects bare-metal deployments only (Azure AKS is explicitly unaffected), and no public exploit code was identified at time of analysis; a vendor fix is available in 1.9.1.
CSRF in Event Gallery for Joomla before 6.5.0 allows a third-party site to upload images to an event and overwrite existing files with the same filename when an authenticated Event Gallery user with image-upload rights is tricked into loading an attacker-controlled page. The attacker does not need authentication, but the attack requires an active victim session and victim interaction; impact is limited to file integrity within event galleries, with no data theft or code execution. No public exploit identified at time of analysis; risk is low-to-moderate despite the medium CVSS.
Cross-site request forgery (CSRF) in the Event Gallery extension for Joomla (versions before 6.5.0) allows an attacker to trick an authenticated backend administrator into deleting orphaned file entries and shopping carts older than 30 days. The attack requires the victim to have an active session and to visit a malicious page; only stale, unreferenced data is affected, not live content. No public exploit code has been identified, and the issue is considered low priority despite a CVSS 4.0 score of 5.1.
AzuraCast deployments before 0.23.8 expose a server-side request forgery and local file read flaw in the AutoDJ remote playlist fetcher, letting an authenticated user who holds the station Media permission point a remote_url playlist at a file:// path or an internal/loopback HTTP endpoint and have the backend fetch it with file_get_contents(). The retrieved lines are stored as queue entries and then disclosed through GET /api/station/{station_id}/queue to any user with the Broadcasting permission, exposing host files readable by the web container (such as /etc/passwd or the application .env) and the bodies of non-blind internal HTTP requests. Exploitation is bounded by valid low-privilege authentication and by the privileges of the web container, and no public exploit code was identified at time of analysis; the advisory data states that no patched version was available at publication, so mitigation depends on disabling PHP allow_url_fopen or tightening Media-permission access.