| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Information leak in Frames in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to leak sensitive information via a crafted HTML page. (Chromium security severity: Low) |
| Information leak in ServiceWorker in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to obtain cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
| Out-of-bounds read in Microsoft Office PowerPoint allows an unauthorized attacker to disclose information over a network. |
| Insertion of Sensitive Information Into Sent Data vulnerability in Drupal DXPR Builder: The Best Editing (AI) Experience for Drupal allows Forceful Browsing. This issue affects DXPR Builder: The Best Editing (AI) Experience for Drupal versions: from 0.0.0 to 2.8.1. |
| Observable discrepancy in Safebrowsing in Google Chrome on on iOS prior to 153.0.8010.36 allowed a remote attacker who had compromised the renderer process to potentially obtain sensitive information via a crafted HTML page. (Chromium security severity: Medium) |
| Information leak in Core in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to leak sensitive information via a crafted HTML page. (Chromium security severity: Low) |
| Information leak in Editing in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to obtain sensitive information via a crafted HTML page. (Chromium security severity: Low) |
| The Loops & Logic WordPress plugin before 4.3.0 does not restrict its public template-data action to the data a visitor is permitted to see, allowing unauthenticated users to read arbitrary user records (including email addresses and roles) and arbitrary site options. |
| In the Linux kernel, the following vulnerability has been resolved:
HID: core: fix number/pointer type confusion on long items
When fetch_item() is called by hid_scan_report() on an item with
HID_ITEM_TAG_LONG, it stores a pointer to the item data in
item->data.longdata instead of storing a value directly in
item->data.{u8/u16/u32}.
When item_udata() or item_sdata() encounters such an item, it incorrectly
assumes that the item is in short format, and therefore returns the lower
part of a kernel pointer reinterpreted as a number.
When a HID device is connected whose descriptor contains a
HID_GLOBAL_ITEM_TAG_REPORT_SIZE encoded in long format with size=4, this
causes the lower half of a kernel pointer to be printed into dmesg as a
number, like this:
hid (null): invalid report_size 107953555
To fix it, let item_udata() and item_sdata() verify that the item is in
short format.
Note that this bug only affects hid_scan_report(), while the main parsing
pass hid_parse_collections() will always bail out when encountering a long
item.
Sidenote: There are currently no users of data.longdata; maybe we should
just remove any parsing of long-format descriptors as a follow-up. |
| Information leak in Transactions Platform in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to obtain sensitive information via a crafted HTML page. (Chromium security severity: Low) |
| Improper input validation in FileAPI in Google Chrome prior to 153.0.8010.36 allowed a remote attacker who had compromised the renderer process to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| Observable discrepancy in Select in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to obtain sensitive information via a crafted HTML page. (Chromium security severity: Low) |
| Observable discrepancy in SVG in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to obtain sensitive information via a crafted HTML page. (Chromium security severity: Low) |
| Observable discrepancy in DOM in Google Chrome prior to 153.0.8010.36 allowed a remote attacker leveraging social engineering to obtain sensitive information via a crafted HTML page. (Chromium security severity: Medium) |
| Observable discrepancy in Autofill in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to obtain sensitive information via a crafted HTML page. (Chromium security severity: Medium) |
| Information leak in Enterprise in Google Chrome on on Windows prior to 153.0.8010.36 allowed a remote attacker to obtain sensitive information via a crafted HTML page. (Chromium security severity: Medium) |
| Information leak in ServiceWorker in Google Chrome prior to 153.0.8010.36 allowed a remote attacker who had compromised the renderer process to obtain sensitive information via a crafted HTML page. (Chromium security severity: Medium) |
| A weakness has been identified in tile-ai tilelang up to 0.1.14. This impacts the function KernelCache._load_kernel_from_disk of the file tilelang/cache/kernel_cache.py of the component Kernel Cache. Executing a manipulation can lead to deserialization. The attack may be performed from remote. This patch is called 11ec2397fe942e8b422d026af4a03d6e0a55ae6c. Applying a patch is advised to resolve this issue. Based on the release information, the fix has not been included in any official release yet. |
| Affected versions of MISP validate the user-configurable homepage by checking only whether the supplied path begins with /. That check is insufficient because protocol-relative URLs such as //attacker.example also begin with / but resolve to an external origin in browsers.
The vulnerable homepage value can be stored as a user setting and later used by the post-login routing logic. The commit explicitly identifies //attacker.example as a payload that passed validation and was emitted to the Location header after login.
The fix introduces a shared InternalRedirectValidator that rejects URLs containing a host, scheme, userinfo, unsafe leading // or /\, malformed URLs, and control characters. It also revalidates homepage settings on read so legacy or internally written unsafe values cannot bypass the new storage-time validation.
Version affected: ≤2.5.45 |
| Affected versions of MISP inconsistently enforced email-address visibility in DashboardsController::listTemplates().
The query always fetched User.email, while redaction happened only inside the non-REST rendering branch. As a result, the same authenticated user who saw redacted data in the normal HTML interface could request the REST/JSON representation and receive template owners’ email addresses without the intended privilege check.
The fix moves the decision to a centralized User::canSeeEmails() authorization helper. Email addresses are now fetched only when the requester is a site administrator or the instance explicitly enables Security.disclose_user_emails. The same helper is also reused by other dashboard widgets to keep email-disclosure policy consistent.
Version affected: ≤2.5.45 |
