| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| OpenAM before 16.1.3 contains an authorization bypass vulnerability in the sessions REST endpoint query operation that allows realm administrators to list sessions of every realm. Attackers holding delegated RealmAdmin privileges can supply a _queryFilter naming another realm to disclose usernames, universal IDs, and session handles across tenant boundaries. |
| In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix reversed sequence option serialization
hton_seq() expects the host-order source first and the unaligned
network-order destination second. The version 1 sync sender passes these
arguments in reverse for both sequence blocks. This leaves 24 bytes of the
kmalloc-backed message unwritten. It may disclose stale heap data and
replace the live connection sequence state with values read from the
buffer.
Pass the connection sequence state as the source and the message payload as
the destination for both blocks. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_sip: fix OOB read in sip_skip_whitespace()
sip_skip_whitespace() returns dptr unchanged when its own loop
exhausts the buffer (dptr == limit), instead of NULL like its sibling
sip_follow_continuation() returns on its own "no more data" path.
ct_sip_get_header() only checks for NULL after calling it:
dptr = sip_skip_whitespace(dptr, limit);
if (dptr == NULL)
break;
if (*dptr != ':' || ++dptr >= limit)
break;
so a recognized header name followed only by spaces/tabs running to
the exact end of the SIP payload, with no colon, makes the very next
statement read one byte past the buffer.
Make both "no more data" outcomes return NULL, matching the
convention sip_follow_continuation() already uses and that both
existing callers already check for. |
| In the Linux kernel, the following vulnerability has been resolved:
media: verisilicon: rockchip: reject AV1 frames exceeding the tile capacity
rockchip_vpu981_av1_dec_set_tile_info() indexes the tile group entry
array by tile1 * tile_cols + tile0, reading up to tile_cols * tile_rows
entries, lays out one descriptor per tile in the AV1_MAX_TILES tile_info
buffer, and programs the real tile_cols / tile_rows into the hardware.
The tile group entry control is a dynamic array sized to the number of
entries userspace submitted, independent of tile_cols / tile_rows, so a
frame that claims more tiles than entries reads past the array. A frame
that claims more than AV1_MAX_TILES tiles also leaves the hardware
programmed for more tiles than the descriptor buffer holds.
Reject both in prepare_run(): tile_cols * tile_rows must not exceed the
submitted entry count or AV1_MAX_TILES. The entry count is read via
v4l2_ctrl_find() (ctrl->elems). This mirrors the bound the mediatek AV1
decoder already enforces. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Zero dport diagnostics buffer to avoid info leak
qla2x00_do_dport_diagnostics() allocates the qla_dport_diag response
buffer with kmalloc_obj() (non-zeroing) and, on success, copies the full
sizeof(*dd) back to user space via sg_copy_from_buffer(). The inbound
sg_copy_to_buffer() only fills as many bytes as the user request payload
provides, and qla26xx_dport_diagnostics() zeroes only dd->buf. The
options and unused[] fields are therefore copied out uninitialized,
leaking kernel heap contents to user space.
Allocate with kzalloc_obj(), matching qla2x00_do_dport_diagnostics_v2(). |
| In the Linux kernel, the following vulnerability has been resolved:
f2fs: limit recovery filename logging to stored length
F2FS stores recovery filenames as a length plus a fixed-size i_name
buffer. The buffer is not NUL-terminated, but recover_inode() and
recover_dentry() print it with %s.
For a 255-byte filename, recovery logging can read past i_name into the
following raw inode fields.
Print the name with a precision bounded by i_namelen and F2FS_NAME_LEN. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: virtio - bound the akcipher result length
virtio_crypto_dataq_akcipher_callback() sets the result length from the
device-reported response length without bounding it to the destination
buffer, which was allocated for the original request length.
sg_copy_from_buffer() then reads that many bytes from the destination
buffer; a backend reporting a larger length over-reads adjacent kernel
heap into the caller's scatterlist (an out-of-bounds read).
Clamp the reported length to the originally requested destination length.
A conforming device reports no more than that, so valid results are
unaffected. |
| In Bouncy Castle for Java LTS before 2.73.13, the one-shot native packet ciphers for AES-CBC, CCM, CFB, CTR, GCM and GCM-SIV released the caller's key, IV and additional authenticated data arrays with JNI's ReleaseByteArrayElements in mode 0, which commits the native copy back into the Java array. Those arrays are read-only to the native code, and on a JVM that returns a copy rather than a pin the copy still holds the input bytes as they were read. The output buffer is taken through a separate critical region and committed first, so where an application passed the same Java array as both an input and the destination - encrypting in place over KeyParameter.getKey(), for example - the later mode-0 release of the key wrote the unchanged key bytes over the ciphertext that had just been produced. The call still returned the correct output length, so an application encrypting in place over its own key array was handed the raw AES key where it expected ciphertext, with nothing in the API to indicate it, and would transmit or store the key in place of the message. The read-only input arrays are now released with JNI_ABORT, freeing the native copy without copying it back, and mode 0 is reserved for arrays the native code wrote. The pure-Java packet ciphers and the streaming native modes are not affected. Bouncy Castle for Java (bcprov) is not affected, as it ships no native implementations. |
| The MPG WordPress plugin before 4.2.3 does not validate that the dataset source supplied when importing a project is a remote URL before treating it as a local filesystem path and copying that file into a publicly accessible uploads folder. This makes it possible for users with the Editor role and above to read the contents of arbitrary files on the server, with the copied file then retrievable by unauthenticated visitors. |
| The WP Ultimate CSV Importer WordPress plugin before 9.2 does not use a site-specific secret when deriving the storage location of the import logs it writes under the uploads directory, nor does it block direct access to them, allowing unauthenticated attackers to retrieve the personal data of users imported from a CSV file. |
| The MetForm WordPress plugin before 4.3.1 does not properly restrict access to form submission data, allowing unauthenticated attackers to view submitter information through the REST API. |
| The MetForm WordPress plugin before 4.3.1 does not properly restrict access to a debug file it writes to the web root on every form submission when its HubSpot Forms integration is enabled, allowing unauthenticated attackers to read upstream API response data, including correlation identifiers and cookies. |
| The Pie Register WordPress plugin before 3.8.4.14 does not restrict access to an invitation-code report, allowing unauthenticated visitors who know a valid invitation code to obtain the username and email address of every user who registered with that code. |
| The WPZOOM Connect: AI Chat, Click to Chat, Social Icons & Share Buttons plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 4.7.3 via the 'x-yamidoo-signature (attacker-obtained via inline_js identify payload)' parameter. This makes it possible for unauthenticated attackers to extract the full customer card — including name, WordPress user ID, order history, order totals, purchased products, payment method labels, and EDD Software Licensing license keys with status and activation counts — for any arbitrary victim email address on the site. Exploitation requires the attacker to register a WooCommerce customer or subscriber-level account with a crafted email address whose local part encodes the target timestamp and victim email, allowing the signature printed into the page HTML by inline_js() to pass verify_request() for an arbitrary victim; both the share_customer_data and identify_logged_in settings are enabled by default, so no non-default configuration is required. |
| Kener 4.0.0 before 4.1.6 contains an information disclosure vulnerability that allows unauthenticated attackers to retrieve hidden or inactive monitor data by querying dashboard API handlers lacking visibility filters. Attackers can supply a known or guessed monitor tag to endpoints such as monitor-bar and monitor-latency-chart to obtain names, descriptions, status, uptime history and latency. |
| Backdrop CMS before 1.35.1 contains an information disclosure vulnerability that allows unauthenticated attackers to retrieve configuration export archives left on the server after transfer. Attackers can download compressed archives generated by users with configuration export permission to obtain the full site configuration, including sensitive settings. |
| Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache HTTP Server's mod_session_cookie module.
When SessionCookieRemove changes across internal redirects, the session cookie may still be passed to a backend server.
This issue affects Apache HTTP Server: from 2.4.0 through 2.4.68. |
| An information exposure vulnerability in Canonical MAAS prior to versions 3.4.10, 3.5.14, 3.6.5, 3.7.3, and 3.8.0 allows an unauthenticated attacker to retrieve the RPC secret in plaintext via the vendor data metadata endpoint. If a target machine was deployed with the 'register as rack' option enabled, an attacker who obtains or infers the machine's system ID can query the preseed/metadata server to leak the secret. |
| - Exposure of Sensitive Information vulnerability in Johnson Controls Easy IO Neo allows Collect Data from Common Resource Locations.
This issue affects Easy IO Neo: before 3.3b63. |
| Information leak in SVG in Google Chrome prior to 154.0.8037.97 allowed a remote attacker to obtain sensitive information via a crafted HTML page. (Chromium security severity: Medium) |