| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Insufficient protection of sensitive information in the user list endpoint in Devolutions Server
2026.3.10.0 and earlier allows an authenticated attacker with delegated user view permissions to obtain the MFA secrets of all users via the user list API response. |
| A insertion of sensitive information into sent data vulnerability in Fortinet FortiMail 7.4.0 through 7.4.2, FortiMail 7.2.0 through 7.2.6, FortiMail 7.0 all versions, FortiManager 7.6.0 through 7.6.1, FortiManager 7.4.1 through 7.4.3, FortiManager Cloud 7.4.1 through 7.4.3, FortiNDR 7.6.0 through 7.6.1, FortiNDR 7.4.0 through 7.4.8, FortiNDR 7.2 all versions, FortiNDR 7.1 all versions, FortiNDR 7.0 all versions, FortiNDR 1.5 all versions, FortiOS 7.6.0, FortiOS 7.4.0 through 7.4.4, FortiOS 7.2.0 through 7.2.8, FortiOS 7.0.0 through 7.0.15, FortiOS 6.4.0 through 6.4.15, FortiOS 6.2 all versions, FortiOS 6.0 all versions, FortiPAM 1.3 all versions, FortiPAM 1.2 all versions, FortiPAM 1.1 all versions, FortiPAM 1.0 all versions, FortiProxy 7.4.0 through 7.4.4, FortiProxy 7.2.0 through 7.2.10, FortiProxy 7.0 all versions, FortiProxy 2.0 all versions, FortiProxy 01.02 all versions, FortiProxy 1.2 all versions, FortiProxy 01.01 all versions, FortiProxy 1.1 all versions, FortiProxy 01.00 all versions, FortiRecorder 7.2.0 through 7.2.1, FortiRecorder 7.0.0 through 7.0.4, FortiTester 7.4.0 through 7.4.2, FortiTester 7.3 all versions, FortiTester 7.2 all versions, FortiTester 7.1 all versions, FortiTester 7.0 all versions, FortiTester 4.2 all versions, FortiVoice 7.0.0 through 7.0.4, FortiVoice 6.4.0 through 6.4.9, FortiVoice 6.0.7 through 6.0.12, FortiWeb 7.6.0, FortiWeb 7.4.0 through 7.4.4, FortiWeb 7.2 all versions, FortiWeb 7.0 all versions, FortiWeb 6.4 all versions allows attacker to disclose sensitive information via specially crafted packets. |
| Storybook is a frontend workshop for building user interface components and pages in isolation. From 8.0.0 until 8.6.19, 9.1.21, 10.6.2, and 11.0.0-alpha.6, the Storybook development server can expose its WebSocket authentication token to clients able to load its HTML pages over a local network. A LAN attacker can obtain the token and invoke WebSocket-backed file-writing or testing functionality. Weak story-write validation can allow code to be placed in story files. If the Storybook Vitest addon is installed with an old version of Vitest, the payload can use a Vitest API to write additional files or execute commands. Depending on the payload and local tooling, the attack can lead to code execution with the developer's privileges. This issue is fixed in 8.6.19, 9.1.21, 10.6.2, and 11.0.0-alpha.6. |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.6.5 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, under certain conditions, an unauthenticated user could have retrieved sensitive internal server credentials due to improper filtering of internal response headers. |
| The smartphone application "Vehicle Inspection Certificate Viewer" contains a vulnerability in which sensitive information may be included in data transmitted by the application, potentially leading to the exposure of API integration credentials such as an access ID and access key. |
| In OpenStack Cinder through 29.0.0, cross-project information disclosure can occur in the Messages API. A non-admin user with the project-scoped 'member' or 'reader' role making the Block Storage API v3.3 "List messages" call finds the non-expired user messages for other projects included in the response, resulting in the leakage of UUIDs of resources owned by other projects, in addition to the user message about the other projects' resources (which, by design, are sanitized generic messages). All Cinder deployments are affected. |
| In versions running on TYPO3 10 and 11, the configured OpenAI API key is embedded in every backend page, so that the editor plugin can contact the OpenAI service directly from the browser. Any authenticated backend user can read the key and use it at the expense of the site operator. This only applies if an API key has been configured. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: fix SMI event cross-process information leak
kfd_smi_ev_enabled() skips the suser privilege check when pid=0.
PROCESS_START, PROCESS_END, and VMFAULT events are emitted with
pid=0 while carrying another process's PID and command name, so any
/dev/kfd user in the render group can monitor all GPU workloads.
Pass the target process PID into kfd_smi_event_add() for these events
so the existing per-client filter restricts delivery to the owning
process or CAP_SYS_ADMIN subscribers. |
| In the Linux kernel, the following vulnerability has been resolved:
cifs: call pagecache_isize_extended() in cifs_setsize() when extending
cifs_setsize() calls truncate_pagecache() but skips
pagecache_isize_extended() on extension. truncate_setsize() shows
the correct pattern:
i_size_write(inode, newsize);
if (newsize > oldsize)
pagecache_isize_extended(inode, oldsize, newsize);
truncate_pagecache(inode, newsize);
pagecache_isize_extended() zeroes the tail of the page straddling old
EOF. Without it, dirty bytes in that region can be written back to
the server, exposing stale data in the newly extended range. |
| An authenticated HTTPS origin can supply an HSTS `max-age` value that the
parser accepts, but time serialization later fails to process. On 64-bit
systems, extreme max-age values compute an absolute expiry within standard
time integer limits that exceeds calendar time structure bounds. During cache
saves, the original HSTS file is truncated before writing a temporary
replacement; when serialization fails, the temporary file is deleted, leaving
an empty or partial cache. Because the save error is silently ignored during
cleanup, curl exits successfully despite the data loss. |
| Importing a `includeSubDomains` parent HSTS entry before a longer-lived child
entry, silently drops the child. Consequently, when the parent expires, the
child's valid HSTS policy is lost, causing curl to issue unencrypted HTTP
requests rather than upgrading to HTTPS. |
| When using ambient user credentials, an HTTP request directed to one origin
may be dispatched over a connection previously authenticated via Negotiate for
a different origin, leaving the request's intended credentials unused. |
| libcurl's connection cache match function never considers the automatic client
certificate option, so a cached, already authenticated Schannel connection can
be handed to a transfer that got redirected to a different origin, even though
the code explicitly switched off the auto client cert option for that transfer
to prevent exactly this. |
| An HTTP proxy can trick libcurl into sending the origin's credentials (Basic
password, or a Negotiate/Kerberos ticket) to the proxy itself, by answering
the `CONNECT` tunnel request with 401 `WWW-Authenticate:` instead of the
expected 407 `Proxy-Authenticate:`. |
| When using an *ambient user* in a first transfer doing Negotiate
authentication and asked to follow redirects, curl could pass on its
credential details to an unrelated second origin when asked to redirect there. |
| Setting `CURLOPT_AWS_SIGV4` to NULL but does not disable SigV4 authentication,
contrary to expectations and documentation. A subsequent transfer on the same
handle still sends an `Authorization: AWS4-HMAC-SHA256` header to whatever URL
isset next, leaking state information. |
| Insertion of Sensitive Information Into Sent Data vulnerability in Shinetheme Traveler Option Tree custom-option-tree allows Retrieve Embedded Sensitive Data.This issue affects Traveler Option Tree: from n/a through 2.8. |
| In the Linux kernel, the following vulnerability has been resolved:
ieee802154: admin-gate legacy LLSEC dump operations
In net/ieee802154/netlink.c, the legacy IEEE802154_NL family ops table
builds the LLSEC dump entries (LLSEC_LIST_KEY, LLSEC_LIST_DEV,
LLSEC_LIST_DEVKEY, LLSEC_LIST_SECLEVEL) with IEEE802154_DUMP() which
sets no .flags, so generic netlink runs them ungated. The modern
nl802154 family admin-gates the equivalent reads via
NL802154_CMD_GET_SEC_KEY and friends with .flags = GENL_ADMIN_PERM.
Any local uid that can open AF_NETLINK / NETLINK_GENERIC can resolve
the "802.15.4 MAC" family and dump LLSEC_LIST_KEY on any wpan netdev
that has an LLSEC key installed; the dump handler writes the raw
16-byte AES-128 key bytes (IEEE802154_ATTR_LLSEC_KEY_BYTES, copied
verbatim from struct ieee802154_llsec_key.key) into the reply.
Recovering the AES key compromises 802.15.4 LLSEC link confidentiality
and authenticity, since LLSEC uses CCM* and the same key authenticates
and encrypts frames.
Impact: any local uid with no capabilities can read the raw 16-byte
AES-128 LLSEC key from the kernel keytable on any wpan netdev that has
an administrator-installed LLSEC key, by issuing an LLSEC_LIST_KEY
dump on the legacy IEEE802154_NL generic-netlink family.
Introduce IEEE802154_DUMP_PRIV() mirroring IEEE802154_DUMP() but
setting .flags = GENL_ADMIN_PERM, and use it for the four LLSEC dump
entries. LIST_PHY and LIST_IFACE retain IEEE802154_DUMP() because the
modern nl802154 family exposes their equivalents to unprivileged
readers by design (NL802154_CMD_GET_WPAN_PHY and
NL802154_CMD_GET_INTERFACE carry "can be retrieved by unprivileged
users" annotations). |
| Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Camel HTTP component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
Two paths handed credentials to a redirect target, which is a host chosen by the remote server rather than by the route, once followRedirects=true. OAuth2ClientConfigurer registers its interceptor with addRequestInterceptorFirst, and HttpClient runs protocol-level request interceptors inside ProtocolExec, which sits below RedirectExec in the exec chain; the interceptor therefore ran again for every redirect hop and re-attached Authorization: Bearer to whatever host the Location header named. Separately, credentials were registered against an AuthScope matching any host, so basic and digest credentials were presented to a redirect target as well. A remote endpoint - or anyone who can influence its responses - could therefore collect the bearer token or the configured credentials simply by answering with a redirect to a host it controls.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Credentials are now sent only to the authority the endpoint was configured with, and are not re-attached when a redirect crosses to another host. For deployments that cannot upgrade immediately, set followRedirects=false on endpoints that carry credentials, and handle any redirect explicitly in the route so that the destination is chosen by the route rather than by the remote server. |
| In Eclipse Jetty, HttpClient may receive a redirect of the form:
```
/secure/../evil
```
If an attacker is able to control the redirects, then HttpClient matches authentication credentials against `/secure` rather than normalizing the path to `/evil`, and will therefore follow the redirect sending the `Authorization` header for `/secure` to `/evil`.
This also mean that the attacker must have an evil application deployed on the same domain as the target. |
