| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| App passwords were allowed to bypass password confirmation on sensitive endpoints. |
| A vulnerability allowing a user with the Veeam Backup for Microsoft 365 Administrator role to read arbitrary files on the backup server with LocalSystem privileges. |
| A vulnerability allowing an unauthenticated attacker to bypass authorization on the CDP Coordinator Service. |
| Cross-Site Request Forgery (CSRF) vulnerability in Tribulant Software Newsletters newsletters-lite allows Cross Site Request Forgery.This issue affects Newsletters: from n/a through 4.18.2. |
| A buffer overflow when handling DEVICE_RESOLUTION in libXi before 1.8.4 could overflow a heap, triggered by a malicious X server. |
| MISP Guard, a proxy-based security filter for MISP feed distribution, contains a case-sensitivity flaw in multiple policy enforcement checks. The functions check_required_taxonomy_exists, check_required_taxonomy_tags_allowed, check_blocked_attribute_categories, and check_blocked_analyst_data_sharing_groups_uuids performed case-sensitive string comparisons when matching event tags, attribute categories, and sharing-group UUIDs against configured allow/block lists.
An attacker with the ability to create or modify events in a MISP instance (or a connected instance that pushes events through the guard) could craft events using different letter case in taxonomy tag names, attribute categories, or sharing-group UUIDs to bypass the configured security policies. For example, if the policy requires the 'tlp' taxonomy with only 'tlp:clear' allowed, an event tagged 'TLP:AMBER' would not be recognized as belonging to the 'tlp' taxonomy and would therefore not be checked against the allowed-tags list, resulting in the event being forwarded to feed consumers. Similarly, a blocked attribute category such as 'Person' would not match a configured block entry of 'person', allowing the attribute to pass through the filter.
The security impact is unauthorized disclosure of threat-intelligence data that the operator intended to restrict. Events carrying non-allowed TLP (Traffic Light Protocol) markings, blocked attribute categories, or blocked sharing-group associations are forwarded to downstream feed consumers in violation of the configured distribution policy. This undermines the confidentiality controls that MISP Guard is designed to enforce.
The vulnerability is trivially exploitable: the attacker only needs to alter the letter case of a tag, category, or UUID string. No authentication beyond normal MISP event-creation privileges is required, and no user interaction is needed. |
| MISP Guard, a proxy that enforces security policies on MISP feed data, contained an incomplete validation check for required taxonomy tags. When a feed event or its attributes carried tags belonging to a required taxonomy (for example, TLP), the guard only verified that at least one tag of that taxonomy matched the configured allowed list. It did not verify that every tag of the required taxonomy present on the event or attribute was in the allowed list. As a result, an event or attribute could simultaneously carry an allowed tag (e.g., tlp:clear) and a non-allowed tag (e.g., tlp:red or tlp:amber) and still pass the guard's policy check. This allowed data marked with a higher classification or sensitivity level to be distributed through feeds configured to only distribute lower-classification data, effectively bypassing the intended data-handling restrictions. The vulnerability affected both event-level and attribute-level tag validation, including attributes nested within objects and shadow attributes. An attacker with the ability to author or modify MISP events in a feed source could include non-allowed taxonomy tags alongside allowed ones to exfiltrate more sensitive data to feed consumers than the guard policy intended to permit. |
| Missing token audience validation in the OAuth authentication mode of AWS API MCP Server before version 1.6.0 might allow local users to run AWS operations with the server's configured AWS credentials via an access token issued to another application by the same identity provider.
To remediate this issue, users should upgrade to version 1.6.0 and configure the expected token audience or client ID for the server. |
| The strapi/content-manager package is missing content-scope authorization in the content manager preview URL endpoint. This allows low-privileged admins to generate preview URLs without knowing document identifiers or holding read permissions. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/cirrus-qemu: Validate BAR0 size during probe
The `cirrus-qemu` driver relies on `CIRRUS_VRAM_SIZE` (4 MB) to validate
framebuffer sizes. However, during PCI probe, the driver mapped BAR0
without verifying that its size matches `CIRRUS_VRAM_SIZE`.
If a PCI device with a BAR0 smaller than 4 MB is bound to the driver, the
mapped VRAM will be smaller than expected. Because validation checks assume
4 MB VRAM, framebuffers larger than the mapped memory can be created.
When the display plane is updated (e.g. during release),
`cirrus_primary_plane_helper_atomic_update()` copies the framebuffer to
VRAM using `drm_fb_memcpy()`. Writing past the end of the mapped I/O memory
causes a supervisor write page fault:
BUG: unable to handle page fault for address: ffffc9000389c000
...
RIP: 0010:memcpy_toio+0x7c/0xe0 arch/x86/lib/iomem.c:110
...
Call Trace:
<TASK>
iosys_map_memcpy_to include/linux/iosys-map.h:285 [inline]
drm_fb_memcpy+0x325/0x5d0 drivers/gpu/drm/drm_format_helper.c:442
cirrus_primary_plane_helper_atomic_update+0x98a/0xb00
drivers/gpu/drm/tiny/cirrus-qemu.c:358
drm_atomic_helper_commit_planes+0x626/0xea0
drivers/gpu/drm/drm_atomic_helper.c:3038
drm_atomic_helper_commit_tail+0x60/0x510
drivers/gpu/drm/drm_atomic_helper.c:1989
commit_tail+0x2b1/0x3c0 drivers/gpu/drm/drm_atomic_helper.c:2074
drm_atomic_helper_commit+0xa77/0xb10
drivers/gpu/drm/drm_atomic_helper.c:2312
Fix this by validating in `cirrus_pci_probe()` that the PCI BAR0 resource
is not less than `CIRRUS_VRAM_SIZE`, returning `-ENODEV` if it is less. |
| The strapi/strapi (Core Admin / Webhook Runner) package is vulnerable to a semi-blind SSRF via a webhook follow-redirect. The webhook dispatcher automatically follows HTTP redirects without performing post-redirect IP resolution or RFC1918/link-local boundary checks. Non-2xx responses from target endpoints are captured and reflected directly back to the caller. |
| The strapi/review-workflows package is vulnerable to a broken access control vulnerability allowing updates to be made without verifying whether the caller possesses update rights for the underlying document. |
| A vulnerability in Veeam Agent for Linux allows for local privilege escalation. Only installations that are managed by a Veeam Backup & Replication instance are affected. |
| A vulnerability allowing an authenticated organization-transfer peer to inject SQL into the configuration database of the source Veeam Backup for Microsoft 365 server, leading to cross-tenant read and write of configuration data and remote code execution as the PostgreSQL service account. |
| A vulnerability allowing an attacker with valid Administrator credentials to bypass multi-factor authentication by disabling it globally before completing MFA verification. |
| A vulnerability allowing an unauthenticated attacker to bypass REST API authentication with a forged federation token and receive responses from REST API endpoints that do not call the Veeam Backup for Microsoft 365 backup service. |
| A vulnerability allowing an authenticated user with the Restore Operator role, who also controls the contents of a backed-up NAS share, to write attacker-controlled files to an arbitrary path on the backup server through relative path traversal. |
| A vulnerability allowing a low-privileged local user to write arbitrary files with SYSTEM privileges during the installation of Veeam Backup for Microsoft 365, which can lead to privilege escalation or denial of service. |
| The user in a group can bypass the group restriction set by an administrator on link sharing, creating share links for a table even though they shouldn't have that permission. |
| The Tables app's share-listing endpoint (GET /apps/tables/share/table/{tableId}) did not verify that the requesting user has manage-level permission on the table before returning the full list of share recipients (users, groups, and teams) along with their permission levels. A user who was only granted read-data access to a table, and who is correctly prevented from seeing this information in the web UI, could call the endpoint directly to enumerate everyone the table is shared with and their access levels.
This does not expose the table's data itself beyond what the read-data grant already permits, only the list of share recipients and their permission levels. |
