PULSE
FEED
ransomhyflock reclama a Ateşsan Ambalaj · TR · Manufacturingransompear reclama a Neiman & Company, Inc. · US · Financial Servicesransomn0n reclama a Company #117 · USransomn0n reclama a Company #116 · USransomn0n reclama a Company #115 · USransomn0n reclama a Company #114 · USransomn0n reclama a Company #113 · USransombyod reclama a Michigan State University · US · Educationransomlockbit5 reclama a synergy.co.id · IDransomshiba reclama a Tema Hwt · DEransomqilin reclama a fzmb GmbH, Forschungszentrum für Medizintechnik und Biotechnologie · DE · Healthcareransomqilin reclama a Global Holding · Otherransomwhitearmor reclama a AmplifAI (GoDaddy instance) · US · Technologyransomdirewolf reclama a My Cloud Grocer · GB · Retail & E-Commerceransomhyflock reclama a Ateşsan Ambalaj · TR · Manufacturingransompear reclama a Neiman & Company, Inc. · US · Financial Servicesransomn0n reclama a Company #117 · USransomn0n reclama a Company #116 · USransomn0n reclama a Company #115 · USransomn0n reclama a Company #114 · USransomn0n reclama a Company #113 · USransombyod reclama a Michigan State University · US · Educationransomlockbit5 reclama a synergy.co.id · IDransomshiba reclama a Tema Hwt · DEransomqilin reclama a fzmb GmbH, Forschungszentrum für Medizintechnik und Biotechnologie · DE · Healthcareransomqilin reclama a Global Holding · Otherransomwhitearmor reclama a AmplifAI (GoDaddy instance) · US · Technologyransomdirewolf reclama a My Cloud Grocer · GB · Retail & E-Commerce
← All CVEs
CVE WatchSep 11, 2026

CVE-2026-33243

barebox is a bootloader. In barebox from version 2016.03.0 to before version 2026.03.1 (and the corresponding backport to 2025.09.3), an att

CVSS

8.2

High

EPSS

0.1%

p1

KEV

—

Exploit Today

0

0-100

Published: Mar 20, 2026 · Last modified: Sep 11, 2026 · CWE-345

EPSS · 30d
0.1%EPSS · 30 days0.1%
2026-10-042026-11-01
Technical description

barebox is a bootloader. In barebox from version 2016.03.0 to before version 2026.03.1 (and the corresponding backport to 2025.09.3), an attacker could exploit a FIT signature verification vulnerability to trick the bootloader into booting different images than those that were verified as part of a signed configuration. mkimage(1) sets the hashed-nodes property of the FIT signature node to list which nodes of the FIT were hashed as part of the signing process as these will need to be verified later on by the bootloader. However, hashed-nodes itself is not part of the hash and could therefore be modified to allow booting different images than those that have been verified. This issue has been patched in barebox versions 2026.03.1 and backported to 2025.09.3.

Official references
Related CVEs
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-1203175.9 MED
—
——0http4k from 4.9.10.0 before 6.60.0.0 contains a missing integrity check vulnerability because DigestEncoder computes the auth-int digest without hashing the request entity body. On-path attackers on non-TLS channels can rewrite the body of authenticated requests while keeping the Authorization header valid, executing state-changing actions as the victim.12h
CVE-2026-631155.3 MED
3.6%
——1ActivityPub is a multi-tenant ActivityPub server for Ghost, built with Fedify. From 1.0.0 until 1.2.6, the `Undo` handler allows a remote federated server to cause the service to act on a `follow` or `repost` as though the activity came from a different account. This permits removal of an existing `follow` relationship or `repost` belonging to another account without that account's involvement. No private data is exposed and content is not modified; the affected relationships can be re-established. Services proxying to Ghost's hosted ActivityPub server have already been updated, while self-hosted services require an updated image and redeployment. This issue is fixed in version 1.2.6.3d
CVE-2026-1192897.1 HIG
7.0%
——2Zuke is a code-first, strongly typed build automation system for Deno. Prior to 1.10.0, the @zuke/gh githubWorkflow(...) gate correlates a dispatched workflow run using only a display-title marker that is visible in the workflow run list and can be copied by another dispatcher. In configurations where the external workflow repository grants workflow_dispatch permission to a party not equally trusted by the releasing repository, an attacker can dispatch a run with the marker and cause the gate to adopt its conclusion without verifying the event, ref, or creation window. A passing substituted run can authorize an unvalidated release, while a failed or cancelled run can block a valid release, and the persisted adopted run ID preserves the substitution across build resume. This issue is fixed in version 1.10.0.3d
CVE-2026-1194225.9 MED
14.8%
——4Juspay Hyperswitch before 1.128.0 contains an authentication bypass vulnerability that allows unauthenticated attackers to forge payment status updates because the Worldpayxml connector's verify_webhook_source always returns true without enforced mTLS. Attackers knowing the merchant_id and Worldpay orderCode can POST unsigned XML with lastEvent SETTLED to the worldpayxml webhook endpoint, marking unpaid payments as charged or triggering refund, dispute and payout events.3d
CVE-2026-930086.8 MED
4.1%
——1A flaw was found in dnsmasq. When following a CNAME in a DNS response, the resolver can cache records for the CNAME target without checking that those records belong to the responding server's authorized zone. In split-DNS deployments that send some domains to a specific upstream, an attacker who controls that upstream can inject cache entries for unrelated names. Later clients may then receive attacker-chosen addresses for those names.4d
CVE-2026-110985—
2.3%
——1A Kafka broker using SASL/OAUTHBEARER with the default validator (sasl.oauthbearer.jwt.validator.class=DefaultJwtValidator) selects its implementation from configuration. When sasl.oauthbearer.jwks.endpoint.url is set, the validator verifies the JWT signature. When that URL is unset (the default) and no verification key resolver is supplied, DefaultJwtValidator silently falls back to ClientJwtValidator, which does not verify the JWT signature, algorithm, or issuer - and the broker starts with no warning or error. This is the residual of CVE-2026-33557, whose fix restored signature verification only on the path where the JWKS endpoint URL is set. Impact: A broker in this state accepts any structurally valid JWT, including "alg":"none" tokens. An unauthenticated remote attacker who can reach the listener can forge a token asserting any principal - including configured superusers - and gain full access to the cluster. Only brokers that enable SASL/OAUTHBEARER validation without a JWKS endpoint URL (and without a custom verification key resolver) are affected; brokers that set the URL verify signatures and are not affected. Unlike CVE-2026-110952 (issuer/audience not enforced by default), here no signature is verified at all. Mitigation (all affected versions, no upgrade required): Set sasl.oauthbearer.jwks.endpoint.url for every listener/mechanism that uses OAuthBearerValidatorCallbackHandler, or configure a signature-verifying sasl.oauthbearer.jwt.validator.class. Resolution: From Apache Kafka 4.2.2, 4.3.1, and 4.4.0: a broker that would fall back to the non-verifying ClientJwtValidator fails to start with a ConfigException instead of running without signature verification (secure by default).4d