| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| IBM Cloud Pak for Business Automation is vulnerable to HTML injection. A remote attacker could inject malicious HTML code, which when viewed, would be executed in the victim's Web browser within the security context of the hosting site. |
| plone.app.textfield provides a zope.schema-style field type called RichText for storing a value with a related MIME type. Prior to 2.0.2, 3.0.2, and 4.0.1, depending on the release line, RichTextValue.output returns an unsanitized stored RichText value when mimeType equals outputMimeType, including values that claim the text/x-html-safe output type. This equality shortcut bypasses the safe_html transform even though the transform itself correctly removes event-handler attributes and unsafe URI schemes. Equal types can result from a RichText field configured with the same mimeType and outputMimeType or from REST API input that supplies text/x-html-safe as its content type. The raw stored value is then emitted through tal:content=structure without escaping, allowing a user who can set a RichText field to store JavaScript that executes in a viewer's browser. This issue is fixed in versions 2.0.2, 3.0.2, and 4.0.1. |
| webhookd is a minimalist webhook server that triggers shell scripts and external processes through HTTP requests. Prior to 1.22.0, webhookd deployments without htpasswd authentication forwarded all incoming HTTP headers through HTTPParamsToShellVars in pkg/api/index.go into the hook script environment without an allowlist. When an upstream reverse proxy did not strip a client-supplied X-WebAuthn-User header and a hook script trusted that variable for identity or privilege, a remote unauthenticated attacker could spoof another user, bypass script security controls, and access or modify resources available to the impersonated identity. This issue is fixed in version 1.22.0. |
| A vulnerability was detected in GNU Binutils 2.47. Affected by this issue is the function _bfd_elf_write_section_eh_frame of the file bfd/elf-eh-frame.c of the component Eh Frame Section Handler. Performing a manipulation of the argument cie_length/fde_length/augmentation_data_size/write_offset results in buffer overflow. Attacking locally is a requirement. The exploit is now public and may be used. The project was informed of the problem early through a bug report but has not responded yet. |
| A security vulnerability has been detected in GNU Binutils 2.47. Affected by this vulnerability is the function elf_x86_64_relocate_section of the file bfd/elf64-x86-64.c of the component ld. Such manipulation of the argument roff leads to buffer overflow. An attack has to be approached locally. The exploit has been disclosed publicly and may be used. Upgrading to version 2.48 addresses this issue. The name of the patch is 471130b39c03623ec6d78ece377ff4da3f6bfe7b. It is recommended to upgrade the affected component. |
| Joomla Extension - joomshaper.com - Unauthenticated CAPTCHA Bypass via Request-Controlled CAPTCHA Configuration in SP Page Builder Pro 5.1.4 - 6.9.0 - The optin_form addon read the CAPTCHA type, the expected answer and the enabled flag from the request rather than from the stored addon configuration. Verification reduced to md5($captcha_question) != $captcha_answer with both operands supplied by the attacker, so any value passed. |
| Traefik is an open source HTTP reverse proxy and load balancer. From 3.2.0 until 3.7.13, Traefik entrypoint defenses aliasHeadersStrategy, underscoreHeadersStrategy, and forwardedHeaders inspect req.Header but not req.Trailer, allowing an unauthenticated client to submit an aliasing or trusted header name in an HTTP/1.1 chunked trailer or an HTTP/2 trailer. When the retry or buffering middleware reads the body before the reverse proxy clones the request, the attacker-controlled trailer value reaches a backend that merges trailers into the header namespace, bypassing the documented delete or reject behavior and potentially spoofing identity or forwarded routing data. This issue is fixed in 3.7.13. |
| Joomla Extension - joomshaper.com - Unauthenticated CAPTCHA Bypass in Module Context in the Contact, Opt-in and Form Builder Addons in SP Page Builder Pro 3.2.6 - 6.9.0 - In the ajax_contact, optin_form and form_builder addons, the result returned by the CAPTCHA plugin's onCheckAnswer event was discarded and replaced with a test for a non-empty string whenever the request-supplied view_type parameter equalled module. Submitting view_type=module together with any arbitrary token value therefore passed verification. This affected every instance of these addons placed inside an SP Page Builder module, irrespective of the CAPTCHA type configured for the site, and the view_type parameter was never validated against the context in which the form was actually rendered. |
| In libxml2 before 2.15.4, there is a heap-based buffer overflow in xmlXPtrEvalXPtrPart because of xmlXPtrEval xpointer length saturation. |
| In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix XDR length calculation in nfsd4_ff_encode_layoutget
The XDR buffer size calculation in nfsd4_ff_encode_layoutget() has
multiple errors that can result in either an out-of-bounds write or
leaking uninitialized kernel memory to the client:
- fh_len doesn't account for XDR padding on the file handle data
- uid and gid lengths use "8 + len" but xdr_encode_opaque() actually
writes "4 + xdr_align_size(len)" bytes
- ds_len omits the flags and stats_collect_hint fields (8 bytes),
while len's header constant overestimates by 8 bytes -- these
partially cancel but leave a net mismatch
The worst case occurs with short strings (e.g. uid=0, gid=0 with an
odd-sized file handle), where the function writes up to 5 bytes past
the reserved XDR buffer. Conversely, when string lengths happen to be
4-byte aligned, the reservation is too large and stale buffer content
is sent to the client.
Fix this by breaking out every encoded field explicitly in the ds_len
calculation, using xdr_align_size() for all variable-length opaque
fields, and correcting the header constants. |
| In the Linux kernel, the following vulnerability has been resolved:
HID: picolcd: clamp eeprom debugfs read to bytes actually received
picolcd_debug_eeprom_read() trusts resp->raw_data[2] -- a length byte
supplied by the device in its REPORT_EE_DATA reply -- clamped only to
the caller's read() count:
ret = resp->raw_data[2];
if (ret > s)
ret = s;
if (copy_to_user(u, resp->raw_data+3, ret))
It never checks resp->raw_size, the number of bytes picolcd_raw_event()
actually copied into the 64-byte raw_data[] of the kmalloc'd struct
picolcd_pending. A device (or a spoofed picoLCD) returning a length byte
of 0xff, read with a count >= 255, makes copy_to_user() read past
raw_data[] into adjacent slab memory and return it to userspace through
the debugfs "eeprom" file:
BUG: KASAN: slab-out-of-bounds in _copy_to_user
Read of size 255 ... picolcd_debug_eeprom_read+0x214/0x2f0 [hid_picolcd]
The debug-dump path in the same file already validates the device length
byte against the received size before trusting it; this read does not.
The file is created S_IRUSR (root-only) and a crafted device is needed,
so it is neither unprivileged- nor remotely-triggerable.
Clamp the copy length to resp->raw_size - 3 (the payload actually
received, minus the 3-byte header), floored at 0 for short replies. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: serial-u16550: Check card index validity at probe
serial-u16550 driver blindly trusts that the given devptr->id value is
within the proper card index range at probe. It's OK for the devices
the driver itself creates at the module probe time, but if the device
is bound manually via sysfs interface, this could be -1 as "none", and
this leads to OOB access for index[] and other parameters.
Add a sanity check for the card index and warn/correct it if it's a
value out of the range. |
| In the Linux kernel, the following vulnerability has been resolved:
vxlan: use pskb_network_may_pull() for transmit path header pulls
In vxlan_xmit(), arp_reduce(), and vxlan_mdb_entry_skb_get(), pskb_may_pull() was
being called to verify the availability of network layer headers (ARP, IPv6/ND,
IP/IPv6 MDB keys).
However, during transmit skb->data points to the MAC header, so skb_network_offset(skb)
is ETH_HLEN (14 bytes). Using pskb_may_pull(skb, len) only checks len bytes from skb->data
rather than skb_network_offset(skb) + len, which can leave part of the network header
in non-linear frags.
Replace these remaining pskb_may_pull() calls with pskb_network_may_pull() to properly
account for the MAC header offset. |
| In the Linux kernel, the following vulnerability has been resolved:
i3c: renesas: Fix out-of-bounds access for newdevs mask
When software initiates DAA (Dynamic Address Assignment), the controller
reports the result via the NRSPQP (Normal Response Queue Port Register).
The data length field of the response descriptor, which is accessible
through the NRSPQP register, indicates the number of devices remaining
after DAA. Consequently, when the bus is empty, this field contains the
maximum number of devices supported by the controller (8 for the Renesas
I3C controller).
Adjust the condition that computes the newly discovered devices bitmask
to prevent an out-of-bounds when the I3C bus is empty. |
| In the Linux kernel, the following vulnerability has been resolved:
zram: fix out-of-bounds access in read_block_state()
read_block_state() calculates nr_pages before taking dev_lock. If the
device is reset and reinitialized with a smaller disksize before lock
acquisition, nr_pages still describes the old table. The subsequent loop
can then call slot_lock() past the end of the newly allocated table.
Read disksize after acquiring dev_lock and checking that the device is
initialized. The read lock then keeps the table and its bound stable for
the duration of the scan. |
| Netty is a network application framework for development of protocol servers and clients. In netty-codec-haproxy prior to versions 4.1.135.Final and 4.2.15.Final, when decoding a PP2_TYPE_SSL TLV, HAProxyMessage.readNextTLV() first calls `header.retainedSlice(header.readerIndex(), length)` and only then reads the 1-byte client field and 4-byte verify field. If the attacker sets the TLV length below 5, the subsequent readByte/readInt throws IndexOutOfBoundsException. HAProxyMessageDecoder only catches HAProxyProtocolException around this call, so the IOOBE propagates and the retained slice on the pooled cumulation buffer is never released. Versions 4.1.135.Final and 4.2.15.Final patch the issue. |
| Renovate is a dependency update automation tool. In versions before 44.3.1 (and Mend Renovate CE/EE images before 15.4.0, mend-renovate-ce Helm chart before 15.4.0, mend-renovate-enterprise-edition Helm chart before 10.4.0), digest updates are not subject to the internal `minimumReleaseAge` (stability age) checks. When a repository configures `minimumReleaseAge` and has dependencies with `updateType=digest` — for example GitHub Actions pinned to a commit SHA with a floating tag, Docker images, Go modules or NuGet packages — Renovate will still open a pull request for a newly published digest, marked only with a pending `renovate/stability-days` status check. A newly published, potentially malicious dependency version can therefore cause a PR to be raised and CI workflows to potentially run before the configured minimum release age has elapsed, which is precisely what the Minimum Release Age control is intended to prevent. The issue is fixed in Renovate 44.3.1; as a workaround, digest updates can be disabled or gated behind `dependencyDashboardApproval`. |
| DeepSeek Harness before 0.1.2-alpha.1 contains an authentication bypass vulnerability that grants unauthenticated access to its local HTTP agent-control API by accepting a client-supplied loopback Host header in place of validating the actual TCP connection origin. On the default configuration, a confined tool-executed process can reach the loopback API without any port exposure and use it to escape its own OS sandbox, escalate to unconfined execution, and disable the approval prompt. When the port is externally reachable via tunnel, SSH forward, or reverse proxy, a remote attacker can exploit the same flaw to create sessions, execute arbitrary commands, and exfiltrate stored conversation transcripts without credentials. |
| OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. OpenEXR versions 3.2.0 through 3.2.10, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13 are vulnerable on ILP32 builds to a heap out-of-bounds read. The issue occurs when a crafted RLE-compressed EXR causes the 64-bit unpacked size to truncate before allocation in OpenEXRCore decoding.c and unpack_32bit() reads beyond the resulting buffer, allowing denial of service. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14. |
| Insufficient policy enforcement in Extensions in Google Chrome prior to 153.0.8010.36 allowed a remote attacker who had compromised the renderer process and leveraged social engineering to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
