Critical security advisoryCriticalFlagged by our vulnerability database: PHP2Shell is on CISA’s exploited list. Most WordPress hosting runs PHP. See if your site is affectedFlagged by our vulnerability database: PHP2Shell is being exploited. DetailsExploited: PHP2Shell. Check your site
HuttenlocherTechnologies
Updated 5 h ago

Vulnerability database

Every flaw the U.S. government’s cybersecurity agency (CISA) has confirmed attackers are using, plus the new WordPress plugin and theme bugs published each day, sorted by what they mean for a small business. We refresh it twice a day. If you see something your website or office runs, tell us.

1,762exploited flaws on CISA’s list
34added in the last 30 days
324new WordPress flaws this week
390,007entries in the database

15 results

  • Oct 11, 2026hyper-mcp through 0.8.3 contains an improper signature verification vulnerability that allows attackers to load malicious WebAssembly plugins because cosign_verCVE-2026-108699 · Other software · hyper-mcp-rs · reported by VulnCheckHigh 8.3

    hyper-mcp through 0.8.3 contains an improper signature verification vulnerability that allows attackers to load malicious WebAssembly plugins because cosign_verify_args() accepts any signer identity and OIDC issuer by default. Attackers controlling a plugin image reference can sign a malicious image with a free Sigstore keyless certificate to execute plugins with configured host, filesystem, and environment capabilities.

    Product
    hyper-mcp
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Oct 11, 2026hyper-mcp through 0.8.3 contains a signature verification bypass vulnerability in load_wasm in src/wasm/oci.rs that verifies the Cosign signature of a separatelCVE-2026-108698 · Other software · hyper-mcp-rs · reported by VulnCheckHigh 8.3

    hyper-mcp through 0.8.3 contains a signature verification bypass vulnerability in load_wasm in src/wasm/oci.rs that verifies the Cosign signature of a separately resolved tag rather than the loaded manifest. Attackers controlling registry responses for the tag can serve an unsigned malicious manifest to the loader and a signed one to Cosign, executing unsigned WebAssembly plugins with configured host capabilities.

    Product
    hyper-mcp
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Apr 7, 2026Cosign provides code signing and transparency for containers and binaries.CVE-2026-39395 · Other software · sigstore · reported by GitHubMedium 4.3

    Cosign provides code signing and transparency for containers and binaries. Prior to 3.0.6 and 2.6.3, cosign verify-blob-attestation may erroneously report a "Verified OK" result for attestations with malformed payloads or mismatched predicate types. For old-format bundles and detached signatures, this was due to a logic flaw in the error handling of the predicate type validation. For new-format bundles, the predicate type validation was bypassed completely. This vulnerability is fixed in 3.0.6 and 2.6.3.

    Product
    cosign
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Mar 10, 2026sigstore-ruby is a pure Ruby implementation of the sigstore verify command from the sigstore/cosign project.CVE-2026-31830 · Other software · sigstore · reported by GitHubHigh 7.5

    sigstore-ruby is a pure Ruby implementation of the sigstore verify command from the sigstore/cosign project. Prior to 0.2.3, Sigstore::Verifier#verify does not propagate the VerificationFailure returned by verify_in_toto when the artifact digest does not match the digest in the in-toto attestation subject. As a result, verification of DSSE bundles containing in-toto statements returns VerificationSuccess regardless of whether the artifact matches the attested subject. This vulnerability is fixed in 0.2.3.

    Product
    sigstore-ruby
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 19, 2026Cosign provides code signing and transparency for containers and binaries.CVE-2026-24122 · Other software · sigstore · reported by GitHubLow 3.7

    Cosign provides code signing and transparency for containers and binaries. In versions 3.0.4 and below, an issuing certificate with a validity that expires before the leaf certificate will be considered valid during verification even if the provided timestamp would mean the issuing certificate should be considered expired. When verifying artifact signatures using a certificate, Cosign first verifies the certificate chain using the leaf certificate's "not before" timestamp and later checks expiry of the leaf certificate using either a signed timestamp provided by the Rekor transparency log or from a timestamp authority, or using the current time. The root and all issuing certificates are assumed to be valid during the leaf certificate's validity. There is no impact to users of the public Sigstore infrastructure. This may affect private deployments with customized PKIs. This issue has been fixed in version 3.0.5.

    Product
    cosign
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Jan 10, 2026Cosign provides code signing and transparency for containers and binaries.CVE-2026-22703 · Other software · sigstore · reported by GitHubMedium 5.5

    Cosign provides code signing and transparency for containers and binaries. Prior to versions 2.6.2 and 3.0.4, Cosign bundle can be crafted to successfully verify an artifact even if the embedded Rekor entry does not reference the artifact's digest, signature or public key. When verifying a Rekor entry, Cosign verifies the Rekor entry signature, and also compares the artifact's digest, the user's public key from either a Fulcio certificate or provided by the user, and the artifact signature to the Rekor entry contents. Without these comparisons, Cosign would accept any response from Rekor as valid. A malicious actor that has compromised a user's identity or signing key could construct a valid Cosign bundle by including any arbitrary Rekor entry, thus preventing the user from being able to audit the signing event. This issue has been patched in versions 2.6.2 and 3.0.4.

    Product
    cosign
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Dec 5, 2025CoSign Single Signon: Reflected Cross-Site ScriptingCVE-2025-13512 · WordPress plugins & themes · reported by WordfenceMedium 6.1

    The CoSign Single Signon plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the `$_SERVER['PHP_SELF']` parameter in all versions up to, and including, 0.3.1 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link.

    Product
    CoSign Single Signon
    Affected
    up to 0.3.1
    What to do
    Affects up to 0.3.1. Update CoSign Single Signon to the newest version and check its changelog mentions this fix; if there isn’t one yet, deactivate it until there is.
  • Apr 10, 2024Cosign provides code signing and transparency for containers and binaries.CVE-2024-29903 · Other software · sigstore · reported by GitHubMedium 4.2

    Cosign provides code signing and transparency for containers and binaries. Prior to version 2.2.4, maliciously-crafted software artifacts can cause denial of service of the machine running Cosign thereby impacting all services on the machine. The root cause is that Cosign creates slices based on the number of signatures, manifests or attestations in untrusted artifacts. As such, the untrusted artifact can control the amount of memory that Cosign allocates. The exact issue is Cosign allocates excessive memory on the lines that creates a slice of the same length as the manifests. Version 2.2.4 contains a patch for the vulnerability.

    Product
    cosign
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Apr 10, 2024Cosign provides code signing and transparency for containers and binaries.CVE-2024-29902 · Other software · sigstore · reported by GitHubMedium 4.2

    Cosign provides code signing and transparency for containers and binaries. Prior to version 2.2.4, a remote image with a malicious attachment can cause denial of service of the host machine running Cosign. This can impact other services on the machine that rely on having memory available such as a Redis database which can result in data loss. It can also impact the availability of other services on the machine that will not be available for the duration of the machine denial. The root cause of this issue is that Cosign reads the attachment from a remote image entirely into memory without checking the size of the attachment first. As such, a large attachment can make Cosign read a large attachment into memory; If the attachments size is larger than the machine has memory available, the machine will be denied of service. The Go runtime will make a SigKill after a few seconds of system-wide denial. This issue can allow a supply-chain escalation from a compromised registry to the Cosign user: If an attacher has compromised a registry or the account of an image vendor, they can include a malicious attachment and hurt the image consumer. Version 2.2.4 contains a patch for the vulnerabili

    Product
    cosign
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Nov 7, 2023Cosign is a sigstore signing tool for OCI containers.CVE-2023-46737 · Other software · sigstore · reported by GitHubLow 3.1

    Cosign is a sigstore signing tool for OCI containers. Cosign is susceptible to a denial of service by an attacker controlled registry. An attacker who controls a remote registry can return a high number of attestations and/or signatures to Cosign and cause Cosign to enter a long loop resulting in an endless data attack. The root cause is that Cosign loops through all attestations fetched from the remote registry in pkg/cosign.FetchAttestations. The attacker needs to compromise the registry or make a request to a registry they control. When doing so, the attacker must return a high number of attestations in the response to Cosign. The result will be that the attacker can cause Cosign to go into a long or infinite loop that will prevent other users from verifying their data. In Kyvernos case, an attacker whose privileges are limited to making requests to the cluster can make a request with an image reference to their own registry, trigger the infinite loop and deny other users from completing their admission requests. Alternatively, the attacker can obtain control of the registry used by an organization and return a high number of attestations instead the expected number of attestati

    Product
    cosign
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Sep 14, 2022Cosign is a project under the sigstore organization which aims to make signatures invisible infrastructure.CVE-2022-36056 · Other software · sigstore · reported by GitHubMedium 5.5

    Cosign is a project under the sigstore organization which aims to make signatures invisible infrastructure. In versions prior to 1.12.0 a number of vulnerabilities have been found in cosign verify-blob, where Cosign would successfully verify an artifact when verification should have failed. First a cosign bundle can be crafted to successfully verify a blob even if the embedded rekorBundle does not reference the given signature. Second, when providing identity flags, the email and issuer of a certificate is not checked when verifying a Rekor bundle, and the GitHub Actions identity is never checked. Third, providing an invalid Rekor bundle without the experimental flag results in a successful verification. And fourth an invalid transparency log entry will result in immediate success for verification. Details and examples of these issues can be seen in the GHSA-8gw7-4j42-w388 advisory linked. Users are advised to upgrade to 1.12.0. There are no known workarounds for these issues.

    Product
    cosign
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Aug 4, 2022cosign is a container signing and verification utility.CVE-2022-35929 · Other software · sigstore · reported by GitHubHigh 7.1

    cosign is a container signing and verification utility. In versions prior to 1.10.1 cosign can report a false positive if any attestation exists. `cosign verify-attestation` used with the `--type` flag will report a false positive verification when there is at least one attestation with a valid signature and there are NO attestations of the type being verified (--type defaults to "custom"). This can happen when signing with a standard keypair and with "keyless" signing with Fulcio. This vulnerability can be reproduced with the `distroless.dev/static@sha256:dd7614b5a12bc4d617b223c588b4e0c833402b8f4991fb5702ea83afad1986e2` image. This image has a `vuln` attestation but not an `spdx` attestation. However, if you run `cosign verify-attestation --type=spdx` on this image, it incorrectly succeeds. This issue has been addressed in version 1.10.1 of cosign. Users are advised to upgrade. There are no known workarounds for this issue.

    Product
    cosign
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Feb 18, 2022Cosign provides container signing, verification, and storage in an OCI registry for the sigstore project.CVE-2022-23649 · Other software · sigstore · reported by GitHubLow 3.3

    Cosign provides container signing, verification, and storage in an OCI registry for the sigstore project. Prior to version 1.5.2, Cosign can be manipulated to claim that an entry for a signature exists in the Rekor transparency log even if it doesn't. This requires the attacker to have pull and push permissions for the signature in OCI. This can happen with both standard signing with a keypair and "keyless signing" with Fulcio. If an attacker has access to the signature in OCI, they can manipulate cosign into believing the entry was stored in Rekor even though it wasn't. The vulnerability has been patched in v1.5.2 of Cosign. The `signature` in the `signedEntryTimestamp` provided by Rekor is now compared to the `signature` that is being verified. If these don't match, then an error is returned. If a valid bundle is copied to a different signature, verification should fail. Cosign output now only informs the user that certificates were verified if a certificate was in fact verified. There is currently no known workaround.

    Product
    cosign
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Apr 25, 2007cosign-bin/cosign.cgi in Cosign 2.0.2 and earlier allows remote authenticated users to perform unauthorized actions as an arbitrary user by using CR (\r) sequenCVE-2007-2233 · Other software · Cosign · reported by MITREMedium 6.5

    cosign-bin/cosign.cgi in Cosign 2.0.2 and earlier allows remote authenticated users to perform unauthorized actions as an arbitrary user by using CR (\r) sequences in the service parameter to inject LOGIN and REGISTER commands with the desired username.

    Product
    Cosign
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.
  • Apr 25, 2007The CHECK command in Cosign 2.0.1 and earlier allows remote attackers to bypass authentication requirements via CR (\r) sequences in the cosign cookie parameterCVE-2007-2232 · Other software · Cosign · reported by MITREHigh 7.5

    The CHECK command in Cosign 2.0.1 and earlier allows remote attackers to bypass authentication requirements via CR (\r) sequences in the cosign cookie parameter.

    Product
    Cosign
    What to do
    Apply the vendor’s update. The NVD record links to the advisory.

Where this comes from: the exploited list is CISA’s Known Exploited Vulnerabilities catalog. Everything else is the whole National Vulnerability Database, where each record is published by the team that found the bug (Wordfence, Patchstack, WPScan, the vendors themselves and others); we show who. Exploit odds are FIRST’s EPSS, updated daily. Titles and categories are ours, so check the linked record before acting on a detail. For a write-up of the big ones, see our advisories. Every vendor, and every WordPress plugin and theme with a recorded flaw, also has its own page. All of it is free to reuse as JSON, CSV or RSS.

Weekly security brief

The flaws that hit local websites, every Friday.

One short email: what got exploited this week, which WordPress plugins broke, and what to check. Unsubscribe in one click.

Get in touch

Tell us what you're building.

A website, your marketing, a security check, an app, or the thing you've been running out of a spreadsheet for three years. A few lines is plenty.

01The person who'll do the work writes back
02A short call, then a written plan with the price
03Nothing starts until you say yes
04Hacked or down right now? Call, and we pick up the same day
843-331-6339

Not ready to talk yet? Run the free website check and see what Google sees.

What do you need?
Build
Grow
Protect
Urgent

No newsletter, no sales sequence. Just a reply.