Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: atm: fix crash due to unvalidated vcc pointer in sigd_send()<br /> <br /> Reproducer available at [1].<br /> <br /> The ATM send path (sendmsg -&gt; vcc_sendmsg -&gt; sigd_send) reads the vcc<br /> pointer from msg-&gt;vcc and uses it directly without any validation. This<br /> pointer comes from userspace via sendmsg() and can be arbitrarily forged:<br /> <br /> int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0);<br /> ioctl(fd, ATMSIGD_CTRL); // become ATM signaling daemon<br /> struct msghdr msg = { .msg_iov = &amp;iov, ... };<br /> *(unsigned long *)(buf + 4) = 0xdeadbeef; // fake vcc pointer<br /> sendmsg(fd, &amp;msg, 0); // kernel dereferences 0xdeadbeef<br /> <br /> In normal operation, the kernel sends the vcc pointer to the signaling<br /> daemon via sigd_enq() when processing operations like connect(), bind(),<br /> or listen(). The daemon is expected to return the same pointer when<br /> responding. However, a malicious daemon can send arbitrary pointer values.<br /> <br /> Fix this by introducing find_get_vcc() which validates the pointer by<br /> searching through vcc_hash (similar to how sigd_close() iterates over<br /> all VCCs), and acquires a reference via sock_hold() if found.<br /> <br /> Since struct atm_vcc embeds struct sock as its first member, they share<br /> the same lifetime. Therefore using sock_hold/sock_put is sufficient to<br /> keep the vcc alive while it is being used.<br /> <br /> Note that there may be a race with sigd_close() which could mark the vcc<br /> with various flags (e.g., ATM_VF_RELEASED) after find_get_vcc() returns.<br /> However, sock_hold() guarantees the memory remains valid, so this race<br /> only affects the logical state, not memory safety.<br /> <br /> [1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3

*** Pendiente de traducción *** A container privilege escalation flaw was found in certain Web Terminal images. This issue stems from the /etc/passwd file being created with group-writable permissions during build time. In certain conditions, an attacker who can execute commands within an affected container, even as a non-root user, can leverage their membership in the root group to modify the /etc/passwd file. This could allow the attacker to add a new user with any arbitrary UID, including UID 0, leading to full root privileges within the container.

*** Pendiente de traducción *** A container privilege escalation flaw was found in certain OpenShift Update Service (OSUS) images. This issue stems from the /etc/passwd file being created with group-writable permissions during build time. In certain conditions, an attacker who can execute commands within an affected container, even as a non-root user, may be able to leverage their membership in the root group to modify the /etc/passwd file. This could allow the attacker to add a new user with any arbitrary UID, including UID 0, leading to full root privileges within the container.

*** Pendiente de traducción *** A container privilege escalation flaw was found in certain Red Hat Process Automation Manager images. This issue stems from the /etc/passwd file being created with group-writable permissions during build time. In certain conditions, an attacker who can execute commands within an affected container, even as a non-root user, can leverage their membership in the root group to modify the /etc/passwd file. This could allow the attacker to add a new user with any arbitrary UID, including UID 0, leading to full root privileges within the container.

*** Pendiente de traducción *** A container privilege escalation flaw was found in certain Ansible Automation Platform images. This issue arises from the /etc/passwd file being created with group-writable permissions during the build process. In certain conditions, an attacker who can execute commands within an affected container, even as a non-root user, can leverage their membership in the root group to modify the /etc/passwd file. This vulnerability allows an attacker to add a new user with any arbitrary UID, including UID 0, gaining full root privileges within the container.

*** Pendiente de traducción *** A container privilege escalation flaw was found in certain Multicluster Engine for Kubernetes images. This issue stems from the /etc/passwd file being created with group-writable permissions during build time. In certain conditions, an attacker who can execute commands within an affected container, even as a non-root user, can leverage their membership in the root group to modify the /etc/passwd file. This could allow the attacker to add a new user with any arbitrary UID, including UID 0, leading to full root privileges within the container.

*** Pendiente de traducción *** Cleartext Storage of Sensitive Information vulnerability in Mitsubishi Electric GENESIS64 versions 10.97.3 and prior, Mitsubishi Electric ICONICS Suite versions 10.97.3 and prior, Mitsubishi Electric MobileHMI versions 10.97.3 and prior, Mitsubishi Electric Hyper Historian versions 10.97.3 and prior, Mitsubishi Electric AnalytiX versions 10.97.3 and prior, Mitsubishi Electric GENESIS versions 11.02 and prior, Mitsubishi Electric MC Works64 all versions, Mitsubishi Electric Iconics Digital Solutions GENESIS64 versions 10.97.3 and prior, Mitsubishi Electric Iconics Digital Solutions ICONICS Suite versions 10.97.3 and prior, Mitsubishi Electric Iconics Digital Solutions MobileHMI versions 10.97.3 and prior, Mitsubishi Electric Iconics Digital Solutions Hyper Historian versions 10.97.3 and prior, Mitsubishi Electric Iconics Digital Solutions AnalytiX versions 10.97.3 and prior, and Mitsubishi Electric Iconics Digital Solutions GENESIS versions 11.02 and prior allows a local attacker to disclose the SQL Server credentials stored in plaintext within the local SQLite file by exploiting this vulnerability, when the local caching feature using SQLite is enabled and SQL authentication is used for the SQL Server authentication. As a result, the unauthorized attacker could access the SQL Server and disclose, tamper with, or destroy data on the server, potentially cause a denial-of-service (DoS) condition on the system.

*** Pendiente de traducción *** Cleartext Storage of Sensitive Information in GUI vulnerability in Mitsubishi Electric GENESIS64 versions 10.97.3 and prior, Mitsubishi Electric ICONICS Suite versions 10.97.3 and prior, Mitsubishi Electric MobileHMI versions 10.97.3 and prior, Mitsubishi Electric Hyper Historian versions 10.97.3 and prior, Mitsubishi Electric AnalytiX versions 10.97.3 and prior, Mitsubishi Electric GENESIS versions 11.02 and prior, Mitsubishi Electric MC Works64 all versions, Mitsubishi Electric Iconics Digital Solutions GENESIS64 versions 10.97.3 and prior, Mitsubishi Electric Iconics Digital Solutions ICONICS Suite versions 10.97.3 and prior, Mitsubishi Electric Iconics Digital Solutions MobileHMI versions 10.97.3 and prior, Mitsubishi Electric Iconics Digital Solutions Hyper Historian versions 10.97.3 and prior, Mitsubishi Electric Iconics Digital Solutions AnalytiX versions 10.97.3 and prior, and Mitsubishi Electric Iconics Digital Solutions GENESIS versions 11.02 and prior allows a local attacker to disclose the SQL Server credentials displayed in plain text in the GUI of the Hyper Historian Splitter feature by exploiting this vulnerability, when SQL authentication is used for the SQL Server authentication. As a result, the unauthorized attacker could access the SQL Server and disclose, tamper with, or destroy data on the server, potentially cause a denial-of-service (DoS) condition on the system.

*** Pendiente de traducción *** Unauthenticated functionality in CoolerControl/coolercontrold

*** Pendiente de traducción *** Stored XSS in log viewer in CoolerControl/coolercontrol-ui

*** Pendiente de traducción *** CORS misconfiguration in CoolerControl/coolercontrold

*** Pendiente de traducción *** A new API endpoint introduced in pretix 2025 that is supposed to <br /> return all check-in events of a specific event in fact returns all <br /> check-in events belonging to the respective organizer. This allows an <br /> API consumer to access information for all other events under the same <br /> organizer, even those they should not have access to.<br /> <br /> <br /> These records contain information on the time and result of every ticket scan as well as the ID of the matched ticket. Example:<br /> <br /> <br /> {<br /> "id": 123,<br /> "successful": true,<br /> "error_reason": null,<br /> "error_explanation": null,<br /> "position": 321,<br /> "datetime": "2020-08-23T09:00:00+02:00",<br /> "list": 456,<br /> "created": "2020-08-23T09:00:00+02:00",<br /> "auto_checked_in": false,<br /> "gate": null,<br /> "device": 1,<br /> "device_id": 1,<br /> "type": "entry"<br /> }<br /> <br /> <br /> <br /> An unauthorized user usually has no way to match these IDs (position) back to individual people.