| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Issue summary: OpenSSL QUIC stack does not enforce connection
level flow control for streams. Remote peers may send more bytes
as long as they fit within the stream flow control limits.
Impact summary: A malicious remote peer may exploit the lack of connection
flow control for streams to make the QUIC stack receive ~100MB of memory
instead of 768 KiB (default flow control window size).
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Description: The local QUIC stack advertises two flow control limits
to its remote peer: stream flow control limit and connection flow
control limit. The remote peer must follow both limits when transmitting
stream data.
Whenever the local QUIC stack receives a stream frame, it validates
that the size of the received stream frame stays within flow control limits.
If either limit is exceeded (stream level or connection level), then
the QUIC stack must close the connection with a flow control error.
The vulnerable OpenSSL QUIC stack enforces the stream-level but not
the connection-level limit. To exploit the issue, three conditions must be met:
- the remote peer opens several streams
- each stream must stay within the stream-level flow control limit
- there must be no zero-offset byte sent on any of the streams
(to prevent the vulnerable QUIC stack from consuming data).
By meeting the conditions above, the remote peer may make the local stack
allocate 2 x MAX_STREAMS x (stream flow control limit) bytes
of memory. MAX_STREAMS defaults to 100, and the limit applies to both
bidirectional and unidirectional streams, making it 200 in total. The default
flow control window for a stream is 512kB. The remote peer may
force the vulnerable QUIC stack to allocate 100MB of heap per connection.
FIPS impact: no
The FIPS module is not affected as the QUIC implementation is outside of
the OpenSSL FIPS module boundary. |
| Issue summary: A TLS server that calls SSL_set_SSL_CTX() to switch a
connection to a different SSL_CTX part way through a handshake may access
memory beyond the end of an internal array if the replacement context knows
about more provider signature algorithms than the context the connection was
created from. Applications which never call SSL_set_SSL_CTX() are not
affected.
Impact summary: A remote peer may be able to cause a small out-of-bounds
read, and in some circumstances a fixed-value out-of-bounds write, on the
server heap. This may lead to a Denial of Service.
CWE: CWE-787: Out-of-bounds Write
Description: A TLS connection records how many certificate slots it has
when it is created, taken from the SSL_CTX that created it: the built-in
certificate types plus one slot for each provider TLS-SIGALG entry that
context was aware of. That count sizes an internal array of per-slot
certificate validity flags.
An application may replace a connection's SSL_CTX part way through the
handshake by calling SSL_set_SSL_CTX(), most commonly from a servername
callback in order to serve a different virtual host. Doing so did not
refresh the recorded count. A provider signature algorithm's slot index is
its position in the list of whichever context resolves it, so if the
replacement context is aware of more of them than the original, an
algorithm offered by the peer can resolve to an index beyond the end of the
array. Processing the peer's signature algorithms then reads one four byte
word past the end for each such algorithm and, where the word read is zero,
writes a fixed value over it. A peer offering many of them can corrupt heap
metadata and abort the process.
Only provider signature algorithms which occupy one of the excess slots,
and which the server also has configured, have this effect. Codepoints the
replacement context does not recognise are discarded without being resolved
to a slot, and provider signature algorithms are usable only from TLS 1.3.
The two contexts must therefore be aware of different numbers of provider
signature algorithms, which requires separate library contexts, a provider
loaded between the two being created, or providers which differ in what
they advertise - in 4.0, for example, the default provider advertises SM2
where the FIPS provider does not. A deployment meeting the condition is
also unable to negotiate the affected algorithms with legitimate clients,
since the same stale count hides the corresponding certificates, so the
misconfiguration is likely to be noticed. For that reason, and because the
configuration is not the default, this issue has been assessed as Low
severity.
FIPS impact: no
No FIPS modules are affected by this issue as the affected code is outside
the OpenSSL FIPS module boundary. |
| Horilla is an HR and CRM software. Prior to 1.6.0, the search parameter at /employee/employee-filter-view is reflected by jQuery .html() in employee/templates/employee_nav.html without HTML neutralization. An external attacker can craft and deliver a link that causes JavaScript to execute when an authenticated employee or administrator reaches the employee filter, allowing access to browser-visible session data and actions with the victim's application privileges. This issue is fixed in version 1.6.0. |
| SCBE-AETHERMOORE is a geometric AI governance and evaluation framework. Starting in version 4.0.2 and prior to version 4.2.1, the AetherBrowser API server (`scripts/aetherbrowser/api_server.py`) exposes the `POST /api/ops/check-email` endpoint without any authentication. Any remote attacker can call this endpoint and trigger execution of the `email_reader.py` subprocess, which connects to configured ProtonMail or Gmail accounts via IMAP and returns email metadata (sender, subject, body snippet) in the JSON response. The server binds to `0.0.0.0:8100` by default with CORS set to `allow_origins=["*"]`, making it reachable from any network or browser origin. Version 4.2.1 patches the issue. |
| GLPI is a free asset and IT management software package. From 11.0.6 until 11.0.8, an authenticated technician can store active markup in supplier website fields. Any user who opens the affected item's suppliers list triggers the stored cross-site scripting payload. This issue is fixed in version 11.0.8. |
| Issue summary: A non-constant-time optimized implementation of scalar
point multiplication is used for SM2 private key operations on ARM64 and
RISC-V platforms.
Impact summary: An attacker able to measure the time taken by, or to observe
the cache-line access pattern of SM2 signing or decryption on an affected
platform can learn information about the secret scalar.
CWE: CWE-208: Observable Timing Discrepancy
Description: On ARM64 and RISC-V processors, the SM2 curve uses an optimized
scalar multiplication implementation whose conditional branches and table
look ups are chosen according to the bits of the secret scalar. The execution
time and the cache-access pattern therefore depend on the long-term private
key (during SM2 decryption) or the per-signature nonce (during SM2 signature
generation), forming a timing and cache side-channel.
FIPS Impact: no
SM2 is not a FIPS algorithm and the optimized SM2 implementation is not part
of the FIPS module.
OpenSSL 4.0, 3.6, 3.5 and 3.4 are vulnerable to this issue on AArch64 and
RISC-V.
OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue.
OpenSSL 4.0 users should upgrade to OpenSSL 4.0.3.
OpenSSL 3.6 users should upgrade to OpenSSL 3.6.5.
OpenSSL 3.5 users should upgrade to OpenSSL 3.5.9.
OpenSSL 3.4 users should upgrade to OpenSSL 3.4.8.
This issue was reported on 2 May 2026 by Abhinav Agarwal.
It was independently reported on 6 June 2026 by Feng Xue.
The fix was developed by Igor Ustinov.
-- cut (non-publishing metadata for internal use) --
Reported by: Abhinav Agarwal, Feng Xue
Fixed by: Igor Ustinov |
| Issue summary: The generic elliptic-curve scalar multiplication used for
ECDSA and SM2 signature operations with curves that do not have a dedicated
implementation leaks information about the secret nonce through timing.
Impact summary: An attacker able to measure signing times may learn
information about the per-signature secret nonce, which over many signatures
can, via a lattice / Hidden Number Problem attack, lead to recovery of the
private key.
CWE: CWE-208: Observable Timing Discrepancy
Description: The generic elliptic-curve scalar multiplication used for
curves that do not have a dedicated constant-time implementation pads the
secret scalar with non-constant-time BIGNUM operations, so the time taken
depends on the value of the secret scalar derived from the ECDSA and SM2 nonce.
The leak is very small; observing it requires a large number of
measurements. The effect is largest for curves whose group order lies
on a machine-word boundary, such as brainpoolP384r1.
Applications using ECDSA signing over the Brainpool and other generic prime
curves, and SM2 signing on platforms that use the generic implementation,
are vulnerable to this issue.
The NIST curves P-256, P-384 and P-521 use dedicated constant-time
implementations and are not affected.
FIPS Impact: no
The FIPS modules are not affected: the approved NIST curves used in the FIPS
provider have dedicated constant-time implementations and do not use the
affected code path. |
| GLPI is a free asset and IT management software package. From 11.0.0 until 11.0.8, an attacker can craft a URL for a dashboard that reflects attacker-controlled markup without sufficient output encoding. A user who opens the crafted URL triggers reflected cross-site scripting in the dashboard. This issue is fixed in version 11.0.8. |
| GLPI is a free asset and IT management software package. From 0.70 until 10.0.26 and 11.0.8, an authenticated hotliner or technician can submit crafted criteria through the user import feature to bypass the configured default LDAP filter. This allows access to LDAP objects that the default filter was intended to exclude. This issue is fixed in versions 11.0.8 and 10.0.26. |
| Marmite through 0.4.2 contains missing authentication in the development server endpoints /__marmite__/content, /__marmite__/config, and /__marmite__/file/, allowing unauthenticated attackers to create, modify, and overwrite site content and configuration. Attackers can exploit unsanitized path parameters in handle_create_content and handle_clone_content to write files outside the project directory via directory traversal. |
| OpenClaw before 2026.9.4 contains an incorrect authorization vulnerability in the mcp.app.view method that allows read-scoped operators to execute MCP App tools requiring operator.write scope. Attackers with operator.read tokens can obtain a standalone ticket from mcp.app.view and redeem it at the MCP app view endpoint to invoke state-changing tools without proper authorization checks. |
| Ollama versions 0.14.0 before 0.31.2 contain an incorrect authorization vulnerability in the experimental agent mode Bash tool approval mechanism that fails to properly parse shell syntax. Attackers who can influence model output through prompt injection can execute additional shell commands by appending control operators like semicolons or logical operators to approved commands, bypassing the session approval requirement. |
| Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 41.10.6, 42.9.2, 43.4.1, and 44.0.0-beta.5, responses served through protocol.registerFileProtocol or protocol.registerHttpProtocol for a custom scheme registered with supportFetchAPI enabled but corsEnabled disabled could remain script-readable across origins. This residual issue completes the remediation for CVE-2026-70604. Applications are affected only when they expose such a scheme and load untrusted content in the same session. Schemes intentionally registered with corsEnabled enabled remain cross-origin readable by design. This issue is fixed in versions 41.10.6, 42.9.2, 43.4.1, and 44.0.0-beta.5. |
| Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 41.10.6, 42.9.2, 43.4.1, and 44.0.0-beta.5, windows opened from a sandboxed top-level document did not inherit that document's active HTML sandbox restrictions. Untrusted content in a sandboxed top-level document that was permitted to open popups could therefore create a window with the Electron application's full origin instead of the restricted origin intended by the sandbox. Applications that deny such popups with setWindowOpenHandler are not affected. This issue is fixed in versions 41.10.6, 42.9.2, 43.4.1, and 44.0.0-beta.5. |
| SGLang through 0.5.20 in prefill/decode disaggregation mode fails to validate duplicate bootstrap_room fields in /generate requests with Mooncake KV transfer backend. Unauthenticated attackers can send concurrent requests with identical bootstrap_room values to crash scheduler processes or hang other users' requests until transfer timeout. |
| Pardus Parental Control before 0.7.0 contains an incorrect authorization vulnerability in the polkit policy that allows unprivileged local users to disable parental controls as root. Attackers can invoke PPCActivator.py with the --disable argument via pkexec to remove all restrictions including DNS filtering and application limits without authentication. |
| A flaw was found in libsoup. When handling an incoming WebSocket Pong frame, SoupWebsocketConnection emitted the ::pong signal with a GByteArray pointer even though the signal is declared to pass a GBytes. Applications connecting a handler that follows the documented GBytes API can trigger heap corruption or a crash upon receiving a crafted Pong. |
| GestSup versions before 3.2.62 fail to properly sanitize HTML email bodies in the IMAP LOGIN connector, allowing unauthenticated attackers to store arbitrary JavaScript in ticket descriptions and replies. Attackers can send emails to the monitored mailbox containing script tags and event handlers that execute in technician browsers, enabling ticket data theft and unauthorized actions. |
| mall4j through 4.0 contains an insufficient session expiration vulnerability in the token refresh endpoint that fails to validate the enabled flag when issuing new sessions. Disabled user accounts can indefinitely renew their sessions through the POST /token/refresh endpoint, retaining access that account disabling was intended to remove. |
| mall4j through 4.0 fails to validate the sysType field in sa-token sessions, allowing storefront customers to authenticate as back-office users by reusing their session tokens. Attackers can register on the public storefront and use their customer session token to access admin endpoints lacking @PreAuthorize permission checks, including menu listings, file uploads, and configuration endpoints. |
