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.
Stack-based buffer overflow in the Edimax BR-6428nC wireless router (firmware version 1.16) allows an authenticated remote attacker to corrupt memory by sending crafted interface1 or interface2 parameters to the /goform/formWizSurvey endpoint, potentially achieving code execution or causing a denial of service. Publicly available exploit code exists, and the severity signals conflict sharply: the CVE publisher assigned a CVSS 4.0 score of 2.1 (low), while our independent assessment rates it 8.8 (high) under CVSS 3.1 due to high confidentiality, integrity and availability impact. No confirmed active exploitation (CISA KEV) has been reported at time of analysis.
Missing authentication in loginlinkstudent.php of Mathurvishal CloudClassroom-PHP-Project allows remote unauthenticated attackers to bypass login checks by manipulating the umail parameter, potentially gaining access to student-scoped functions and data. The vulnerability (CVE-2026-100876) has a publicly available exploit, but no active exploitation has been confirmed. The independent assessment rates it as a genuine but low-priority issue due to the product's obscure, unversioned hobby-project nature and negligible real-world deployment.
Cross-site request forgery in the CloudClassroom-PHP-Project PHP web application (repository state up to commit 5dadec098bfbbf3300d60c3494db3fb95b66e7be) allows a remote attacker to cause a logged-in victim's browser to submit unintended, state-changing requests against the application without the victim's knowledge. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P) and our independent CVSS 3.1 assessment (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N) agree that no attacker-side authentication is required but that a currently authenticated victim must be socially engineered into loading attacker-controlled content, which caps the realistic impact at low integrity modification rather than code execution or data disclosure. Publicly available exploit code exists (a public advisory with a CSRF proof-of-concept), but there is no evidence of confirmed active exploitation (not in CISA KEV), and the vendor did not respond to disclosure, so no official fix is available.
Missing authorization in zhistaredu StarTraining up to and including version 3.8.1 lets any authenticated low-privilege user invoke privileged role-management operations through the dataScope endpoint, because the checkRoleAllowed function in SysRoleServiceImpl.java performs role CRUD without an authorization guard. Exploitation requires only a valid low-privilege account (CVSS 4.0 PR:L, network reachable) and no user interaction; the outcome is integrity-low role and data-scope tampering with no direct confidentiality or availability impact. Publicly available exploit code exists (referenced from the ArrestX/startraining-advisories ST-VULN-005 advisory) and the vendor did not respond to early disclosure, so no vendor-released patch has been identified at time of analysis; the product has a small deployment base, which limits real-world exposure.
Authenticated SQL injection in the order_by() method of DB_query_builder.php in amirsanni's Mini-Inventory-and-Sales-Management-System lets a remote attacker holding valid low-privilege credentials manipulate the orderBy argument and inject arbitrary SQL into the ORDER BY clause of generated queries, yielding high-confidence read access to database contents (customer, inventory and sales records, application credentials) and limited data-manipulation potential. Publicly available exploit code exists, but the injection sits in an ORDER BY context, which constrains extraction to blind/inferential or error-based techniques rather than direct UNION result dumping, and an authenticated session is required. The project is abandoned - the maintainer has said it is not worth fixing and follows a rolling release model, so no version-specific patched build is expected; exposure is limited to the small existing deployment base, making this a genuine but low real-world priority.
An insecure direct object reference (IDOR) in Krayin laravel-crm through version 2.2.5 allows any authenticated user to download email attachments belonging to other mailboxes simply by supplying a different attachment ID to the admin attachment-download endpoint. Exploitation requires only a valid low-privileged account on the admin panel, causes confidentiality loss only (no modification or denial of service), and publicly available exploit code exists, which the CVSS 4.0 vector reflects via its E:P (proof-of-concept) exploit maturity rating. Vendor-released patch: 2.2.6, which enforces the mail.view permission on the download action.
Improper access control in Krayin Laravel CRM through 2.2.5 allows an authenticated low-privilege admin user to access administrative functions whose routes are missing from the ACL map, including warehouse settings left unprotected by a route-name typo. The pre-2.2.6 Bouncer middleware failed open for unmapped admin routes, so an attacker who already holds valid admin-backend credentials can invoke functions outside their intended role; publicly available exploit code exists, and upgrading to 2.2.6 fixes the issue. Impact is confined to individual unmapped admin functions rather than full system compromise, making this a moderate-severity broken-access-control flaw.
Authorization bypass in zhistaredu StarTraining through 3.8.1 allows an authenticated low-privileged user to escalate privileges by manipulating the userId/roleIds parameters sent to the authRole endpoint, because the SysUser.isAdmin authorization logic trusts caller-supplied identifiers instead of the authenticated principal. Publicly available exploit code exists (published in the ArrestX StarTraining advisories repository as ST-VULN-004), but there is no evidence of confirmed active exploitation, and no vendor patch has been released. Independent assessment classifies this as a genuine but low-priority issue: exploitation requires a valid low-privileged account, the affected product has a very small footprint, and mitigation currently depends on access controls.
Stored/reflected cross-site scripting in mathurvishal's CloudClassroom-PHP-Project lets remote, unauthenticated attackers submit script payloads through the FName, LName, and Addrs parameters of registrationform.php, which are then rendered unsanitized in a victim's browser. The project is a rolling-release PHP application with no version tags, so every known build up to commit 5dadec098bfbbf3300d60c3494db3fb95b66e7be is presumed affected, and the vendor did not respond to disclosure. Publicly available exploit code exists (a GitHub advisory demonstrating the injection is linked from the CVE record); there is no evidence of confirmed active exploitation (not in CISA KEV), and the practical risk is limited by the near-zero deployment footprint of this project and by the user-interaction requirement (CVSS 4.0 UI:P; independently assessed CVSS 3.1 UI:R) for a victim to view the injected fields.
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.
Stored cross-site scripting in Krayin CRM (laravel-crm) up to and including version 2.2.5 lets an authenticated administrator inject arbitrary JavaScript through the Admin Settings footer label field, which is then rendered unescaped on admin layout pages for any admin who views them. The setting 'general.settings.footer.label' is output with Laravel Blade's raw `{!! !!}` directive in packages/Webkul/Admin/src/Resources/views/components/layouts/index.blade.php, so script content typed into that field executes in the browser of the next admin loading a page containing the footer-effectively an admin-to-admin/self-XSS scenario confined to the admin panel. Publicly available exploit code exists (a dedicated advisory write-up), but there is no KEV confirmation of active exploitation, and the assigned vector (CVSS 4.0 base 1.9; independent assessment CVSS 3.1 AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N) reflects a genuinely low-priority issue despite the public proof of concept. Upgrading to 2.2.6 resolves it.
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.
Cross-site scripting in zhistaredu StarTraining up to and including 3.8.1 becomes exploitable when the built-in XSS filter is switched off by setting xss.enabled to false in the application.yml configuration file. This issue is not independently exploitable: it is a defense-in-depth gap that amplifies the companion injection flaw CVE-2026-100880, and both must be present for an attack to succeed. Exploitation requires authenticated low-privilege access (PR:L) and victim interaction (UI:P) and is rated as highly complex, with the vendor assigning a CVSS base of 2.1; publicly available exploit code exists (published via the ArrestX StarTraining advisories repository), and the vendor was contacted but did not respond, so no vendor-released patch is identified at time of analysis.
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.
Terminal escape sequence injection in the onefetch CLI (through version 2.28.1) lets an attacker who controls a repository's project manifest metadata manipulate the victim's terminal when the victim runs onefetch against that repository. Because the tool writes manifest name and version field values directly to the terminal without neutralizing control characters, embedded ANSI/OSC sequences can rewrite window titles, hide or spoof displayed text, or trigger emulator-specific behavior; the concrete effect depends on the terminal emulator in use. There is no public exploit code identified at time of analysis and no confirmed active exploitation, CVSS is 4.8, and the assessed real-world risk is low-to-medium: the attacker must first get the victim to inspect a repository containing poisoned manifest fields, and exploitation yields display manipulation rather than code execution within onefetch itself.
Terminal escape sequence injection in spaceship-prompt through 4.22.5 allows unauthenticated local attackers to spoof terminal output and manipulate window titles by embedding ANSI/OSC sequences in project manifest version fields when a victim enters a crafted directory. Exploitation requires the victim to have the 'package' section enabled and to navigate into the malicious directory; impact is limited to low integrity of the terminal display with no code execution or data disclosure. No public exploit or active exploitation is known at time of analysis, and the risk is considered low.
Heap use-after-free in wolfSSL's (D)TLS shutdown path can crash or corrupt memory in applications that leave decrypted application data buffered (typically after a wolfSSL_read() with a small user buffer), then call wolfSSL_shutdown() for a bidirectional close, then call wolfSSL_read() again while the peer keeps sending data during shutdown. All builds that use (D)TLS, including default builds, are affected per the vendor's own advisory scope, and the defect was confirmed by wolfSSL in fix PR #10863, which ships a dedicated regression test (test_wolfSSL_shutdown_pending_data_uaf) reproducing the exact sequence. Impact is availability-only - no confidentiality or integrity effect is assessed - and the vendor rates it low severity (CVSS 4.0 2.3, with AC:H and AT:P), consistent with the independent assessment of CVSS 3.1 AV:N/AC:H/PR:N/UI:N/C:N/I:N/A:L; exploitation requires induced timing/state and an attacker who is the connected TLS peer (or a MITM positioned to keep sending during shutdown), and no public exploit identified at time of analysis.
Certificate revocation checking in wolfSSL builds that enable both OCSP and CRL can be silently bypassed, allowing a certificate that the loaded CRL explicitly lists as revoked to be accepted during a TLS/DTLS handshake. Only applications that define both HAVE_OCSP and HAVE_CRL (for example --enable-ocsp --enable-crl, or bundles such as --enable-all, --enable-nginx, --enable-haproxy, --enable-openvpn, --enable-strongswan) and that actually call both wolfSSL_CTX_EnableOCSP() and wolfSSL_CTX_EnableCRL() with a CRL loaded are exposed; OCSP-stapling-only applications are not affected. The CVSS vector indicates the attacker must be positioned as an authenticated peer (PR:L) presenting a crafted certificate, and the independent assessment rates this LOW priority: no public exploit code has been identified at time of analysis and the stacked build-time and configuration prerequisites make practical exploitation unlikely, though the resulting integrity impact is real for affected deployments.
Server-side request forgery in the UTCP Python GraphQL (utcp-gql) and WebSocket (utcp-websocket) plugins at 1.1.0 and earlier lets unauthenticated attackers (CVSS 4.0 vector PR:N, and the assessed 3.1 vector AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N) force the host to open outbound connections to internal services and cloud metadata endpoints such as 169.254.169.254. utcp-gql still relies on a startswith prefix check for http://localhost and http://127.0.0.1, so crafted hostnames like http://127.0.0.1.attacker.example or http://localhost.evil.com satisfy the check and then resolve to any address the attacker's DNS returns, while utcp-websocket performs no URL validation at all despite docstrings claiming it enforces 'WSS or localhost only'. Both plugins attach the call template's configured auth headers to the outbound connection, so a successful SSRF also exfiltrates configured API keys and OAuth tokens to the attacker-controlled host; risk is genuine but low urgency, exploitation requires the victim to ingest an attacker-supplied tool or manual call-template URL (UI:P/UI:R) and, for the GraphQL path, attacker-controlled DNS resolution, and no public exploit identified at time of analysis (no CISA KEV entry, no POC reported).
SQL injection in FleetDM Fleet before 4.89.0 allows an authenticated user holding read access to Activity to influence the ORDER BY clause on the activity list endpoints (GET /api/v1/fleet/activities and GET /api/v1/fleet/hosts/{id}/activities), because the deprecated cursor-pagination helper appendListOptionsWithCursorToSQL interpolated the caller-supplied sort/order key without an allowlist. The impact is read-only and tightly bounded: it acts as a blind sort-order oracle that can only infer values from columns on the activity_past table (e.g. details) that are not otherwise returned, with no write access, no privilege escalation, and no reachability of node_key or host-join columns through these endpoints. Exploitation requires authenticated access plus high attack complexity due to the indirect inference, no public exploit code was identified at time of analysis, and the issue is fixed in 4.89.0.
Cleartext MCP server connections in utcp-mcp (the MCP plugin of python-utcp) through 1.1.2 allow a plain-HTTP or plain-WS, non-loopback MCP server URL to be dialed without the ensure_secure_url check that the HTTP-family plugins enforce, so the HTTPS/WSS-or-loopback rule is silently skipped for call templates. The practical risk is low: exploitation requires an operator to author an mcpServers entry pointing at a non-loopback plaintext URL and an attacker to already hold a man-in-the-middle position on that network path, and the misconfigured channel only carries an MCP handshake rather than an arbitrary request returning a response body. The OAuth2 token_url credential-leak path from the original report is not reachable in affected versions because the OAuth2 handler was never invoked. Remote attackers are unauthenticated (CVSS:4.0 PR:N), no public exploit code has been identified, and there is no confirmed active exploitation (no CISA KEV listing); the root cause is CWE-319, cleartext transmission of sensitive information.
TLS server impersonation in wolfSSL 5.3.0 through 5.9.2 lets an on-path attacker who observes a server-chosen TLS 1.2 session ID poison the client's process-global SessionCache and be accepted as the original peer for the entire lifetime of the resumed connection. The flaw lives in the legacy session-reference flow (wolfSSL_get_session()/SSL_get_session() followed by wolfSSL_set_session()), where the handle is validated only against a hash of the session ID; a second server reusing that ID overwrites the cached master secret, cipher suite and version, and the resulting abbreviated handshake sends no Certificate message, so neither chain verification nor wolfSSL_check_domain_name() ever runs. Reachability is heavily gated - a vulnerable build (NO_SESSION_CACHE_REF, NO_SESSION_CACHE, NO_CLIENT_CACHE and TITAN_SESSION_CACHE all left undefined), an adjacent/on-path attacker, TLS 1.2 or DTLS 1.2 or below, and completion within the default 500-second session timeout - and no public exploit has been identified at time of analysis; the CVSS 4.0 base score is 2.3, though the independent assessment rates confidentiality and integrity impact as high (CVSS 3.1 AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).
A certificate signature-verification bypass exists in wolfSSL builds compiled with WOLFSSL_SMALL_CERT_VERIFY, where the separate signature check performed by ProcessPeerCertParse() is merged back only when the certificate parse returns 0, causing ASN_SIG_CONFIRM_E to be discarded. An unauthenticated remote attacker can present a self-made certificate carrying the expected subject name and the trusted CA's subject as issuer with arbitrary signature bytes, and if the application's verify callback consents to date errors (the shipped myVerify()/VERIFY_OVERRIDE_DATE_ERR shape), the handshake succeeds - a genuine CWE-347 failure whose practical severity far exceeds its low base score because it requires two independent non-default configuration prerequisites. No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV), but the flaw affects TLS 1.2, TLS 1.3 in both directions, and DTLS. Note that the two prerequisites - the compile-time macro and the permissive callback - mean default wolfSSL deployments and applications without a date-overriding callback remain unaffected.
Information disclosure in Nezha before version 2.2.7 allows any authenticated user to retrieve their own bcrypt-hashed password by requesting the GET /api/v1/profile endpoint. While the exposure of password hashes is a security weakness, bcrypt is a deliberately slow, salted hashing algorithm, so offline cracking is only feasible for weak or reused passwords; this makes the issue low-risk. No public exploit code is known, and the vulnerability is not confirmed as actively exploited. The independent assessment rates this as a genuinely low-priority issue (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N), emphasizing that the disclosed hashes are resistant to cracking for strong passwords.
Path traversal in Cloudreve before 4.16.1 lets an authenticated user write downloaded files outside the destination directory they selected, by supplying '..' segments in the file names reported by a configured remote downloader such as aria2. The vulnerability is graded very low (CVSS 4.0 2.3 with attack requirements AT:P; the independent assessment scores CVSS 3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N), because the attacker must control downloader-reported metadata rather than the downloaded HTTP body, and the misplaced writes remain confined to namespaces the user can already reach and are still subject to Cloudreve's normal permission and upload checks. No public exploit code was flagged by the available threat-intelligence feeds, and this CVE is not in CISA KEV; the upstream advisory does document a proof-of-concept harness that emulates an aria2 JSON-RPC service returning a traversal path.
Stored cross-site scripting in zhistaredu StarTraining 3.8.1 and earlier lets an authenticated user upload a file whose MIME type is misclassified by MimeTypeUtils.java, so the content is stored and later rendered as HTML/script in a victim's browser; the attacker's script then executes in the context of the StarTraining web application. Exploitation requires a valid account with access to the Upload Endpoint plus a second user who views the uploaded content, and publicly available exploit code exists. This is a low-real-risk issue despite being a network-reachable stored XSS: the vendor was contacted but never responded, and no vendor-released patch has been identified, so the practical severity is bounded by the credential and user-interaction prerequisites.