CVE Watch2 sept 2026

CVE-2026-82018

IGEL OS 12 before 12.9.0, 12.8.3 LTS and IGEL OS 11 before 11.11.150 contain a secure boot bypass vulnerability in the GRUB boot stage that

CVSS

6.1

Medio

EPSS

0.2%

KEV

—

Exploit Today

0-100

Publicado: 28 ago 2026 · Última mod.: 2 sept 2026 · CWE-636

EPSS · 30d

0.2%EPSS · 30 días0.2%

2026-08-292026-09-02

Descripción técnica

IGEL OS 12 before 12.9.0, 12.8.3 LTS and IGEL OS 11 before 11.11.150 contain a secure boot bypass vulnerability in the GRUB boot stage that allows physically present attackers to gain unauthorized root access by placing an unsigned empty file named igel.conf on a partition. Attackers can exploit GRUB's fail-open signature verification behavior to drop into an interactive GRUB prompt, then boot the device's own kernel with additional command-line arguments to obtain a root shell with the disk unlocked while leaving TPM PCR values unaltered.

Referencias oficiales

CVEs relacionados

CVECVSSEPSSKEVRExplotTítuloVis.

CVE-2026-183298.2 ALT

—

——0Description NGINX JavaScript (njs) and QuickJS (qjs) engines have a vulnerability when a js_access handler performs asynchronous request body processing and an exception is thrown during asynchronous access-control evaluation before an explicit access denial is returned. An unauthenticated attacker can exploit this vulnerability by sending a crafted HTTP request that triggers an error condition in the access validation logic. This may cause the js_access phase to fail open, allowing the request to proceed instead of being denied, resulting in an authentication or authorization bypass and unauthorized access to protected resources. Impact This vulnerability may allow remote attackers to bypass js_access controls. There is no control plane exposure; this is a data plane issue only. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.19h CVE-2026-82744—

3.1%

——1Not Failing Securely (Failing Open) vulnerability in ash-project ash skips an Ash.Reactor change when the guard controlling it raises, so a change meant to run does not. An Ash.Reactor change step can be gated by where validations that decide whether the change runs. Ash.Reactor.ChangeStep (lib/ash/reactor/steps/change_step.ex) evaluated those guards in apply_where_clauses/3, and apply_validation rescued any exception into {:error, error}. The reduce treated that identically to a guard whose condition was simply not met and bypassed the change. So when a guard raises (for example on attacker-influenced input), a change that enforces a security-relevant modification is skipped rather than failing the step. The fix distinguishes a raised exception (now {:raised, error}) and halts the step with an error, failing closed. This issue affects ash: from 3.0.0-rc.17 before 3.32.2.2d CVE-2026-464825.3 MED

25.4%

——8### Impact The registration component does not validate the text-based _Security Question_ CAPTCHA correctly, allowing attackers to bypass the challenge via a specially crafted value. [CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N) ### Details The public _Registration_ workflow ([`member.php?action=do_register`](https://github.com/mybb/mybb/blob/mybb_1839/member.php#L262-L307)) accepts a hidden field `question_id` — expected to match the question session identifier (`mybb_questionsessions.sid`) — and validates the challenge answer without a fail-closed fallback for invalid identifiers. If the value is blank, forged, or expired, the request continues without a question-related error. ### Patches MyBB 1.8.(...) resolves this issue with the following changes: - Commit: https://github.com/mybb/mybb/commit/ - `.patch`: https://github.com/mybb/mybb/commit/.patch ### References - Release Notes: https://mybb.com/versions/1.8.(...)/ ### For more information Go to [mybb.com/security](https://mybb.com/security/) to report possible security concerns or to learn more about security research at MyBB. ### Contact The security team can be reached at [security@mybb.com](mailto:security@mybb.com).16d CVE-2026-73421—

38.2%

——11NextAuth.js provides authentication for Next.js. From next-auth 5.0.0-beta.0 until 5.0.0-beta.32, applications that gate access by checking only for the existence of the auth object returned by the auth() wrapper can fail open when Auth.js has a server configuration error. In middleware, Route Handlers, React Server Components, and other auth() entry points, a non-OK session response is parsed into a truthy error object instead of null, so checks such as !!auth and if (req.auth) evaluate to true for unauthenticated requests. A provider missing both the issuer and authorization endpoint triggers InvalidEndpoints, and an unset AUTH_SECRET or another server configuration error can produce the same behavior. There is no impact while configuration is valid, but after a deployment becomes misconfigured, routes protected only by session existence silently grant access to every visitor. This issue is fixed in next-auth 5.0.0-beta.32.16d CVE-2026-704527.4 ALT