| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A privacy issue was addressed with improved state management. This issue is fixed in iOS 26.7 and iPadOS 26.7, iOS 27 and iPadOS 27, watchOS 27. An app may be able to track users across apps and websites without permission. |
| FreeRDP server versions before 3.31.0 contain a protocol negotiation bypass vulnerability that allows unauthenticated attackers to establish RDSTLS connections despite server policy disabling them. Attackers can send incompatible protocol requests, receive negotiation failures, then complete TLS handshake and enter RDSTLS to bypass pre-authentication transport restrictions. |
| The Sign-up Sheets WordPress plugin before 2.4.0 does not properly validate the CSRF nonce that protects its sign-up deletion action, allowing attackers to delete sign-up records via a forged request handled in the session of a logged-in user with the required capability. |
| Cotonti through 1.0.0 fails to validate anti-CSRF tokens in the contact plugin submission handler, allowing attackers to forge messages. Attackers can auto-submit contact forms from attacker-controlled pages to send forged messages attributed to authenticated victims to the administrator inbox. |
| Concrete CMS 9.0.0 to dashboard group type controller did not validate a CSRF token on its delete action, resulting in cross-site request forgery. A remote unauthenticated attacker could cause an authenticated user with group type management permission to delete a custom group type. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.3 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks riodrwn for reporting. |
| In the Linux kernel, the following vulnerability has been resolved:
thermal: hwmon: Remove hwmon class device along with its parent
The current code creates one hwmon device per thermal zone type and that
device is registered under the first thermal zone of the given type.
That turns out to be problematic when the thermal zone holding the
hwmon device is removed.
For example, say that there are two ACPI thermal zones on a system
/sys/devices/virtual/thermal/thermal_zone0/
/sys/devices/virtual/thermal/thermal_zone1/
The current code registers a hwmon class device for thermal_zone0 only:
/sys/devices/virtual/thermal/thermal_zone0/hwmon0/
because the type is "acpitz" for both of them, but it adds a sysfs
attribute that belongs to thermal_zone1 under it:
/sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp2_input
There is also
/sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp1_input
which belongs to thermal_zone0.
When thermal_zone0 is removed, say because the ACPI thermal driver is
unbound from the underlying platform device, thermal_remove_hwmon_sysfs()
skips the removal of hwmon0 because of the temp2_input attribute
belonging to thermal_zone1 which effectively prevents thermal_zone0
removal from making progress.
Address this by making thermal_remove_hwmon_sysfs() remove the entire
hwmon class device interface for the given thermal zone type when the
thermal zone device holding it is removed.
To prevent races with thermal_add_hwmon_sysfs() that may interfere
with this, carry out the entire addition and removal of hwmon sysfs
interfaces for thermal zones under thermal_hwmon_list_lock.
Also adjust the layout of the labels in thermal_add_hwmon_sysfs() to
the current kernel coding style to align with the new "unlock" label. |
| djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance. Prior to version 1.0.7, when a Django `Model` instance is assigned to a public view attribute, djust serialized it to the client with no sensitive-field denylist — sending fields such as `password` (the hash), privilege flags (e.g. `is_staff` / `is_superuser`), tokens, and other PII to the browser. Because exposing model objects to templates is a normal djust pattern, this could leak credentials/PII without the developer realizing the full object crossed the wire. This is fixed in djust 1.0.7. Model serialization applies a secure-by-default sensitive-field denylist (password/hash/token/secret-style fields and known privilege flags are withheld) with an identity-subset fallback. As a workaround, keep `Model` instances on `_private` attributes and expose only the specific fields needed, until patched. |
| mport is the MidnightBSD Package Manager. Prior to 2.7.8, mport_verify_package() in libmport/verify.c could continue after MD5File() or SHA256_File() failed and compare an expected checksum with stale data in the hash buffer rather than a newly computed digest. An attacker able to influence an installed file or the conditions that make hashing fail could receive a misleading integrity result or hide a checksum failure. This issue is fixed in version 2.7.8. |
| IBM Guardium Data Protection 12.2 could allow a remote attacker to bypass security restrictions due to a cross-site request forgery (CSRF) vulnerability. |
| IBM Guardium Data Protection 12.2 could allow a remote attacker to bypass security restrictions due to a cross-site request forgery vulnerability. |
| Dell OpenManage Server Administrator, versions prior to 11.1.0.3, contains a Cross-Site Request Forgery (CSRF) vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Remote execution. |
| CMAK through 3.0.0.6 fails to install a cross-site request forgery filter, allowing attackers to perform state-changing actions on behalf of authenticated operators. Attackers can craft hidden forms that submit to destructive endpoints like topic deletion and cluster configuration changes, leveraging the operator's HTTP Basic authentication credentials or play-basic-authentication cookie without SameSite protection. |
| A weakness has been identified in gedelumbung HospitalManagement up to c2d45543789a3887067d3915f69d44cfc2cf76a8. This vulnerability affects unknown code. This manipulation causes cross-site request forgery. The attack may be initiated remotely. The exploit has been made available to the public and could be used for attacks. This product uses a rolling release model to deliver continuous updates. As a result, specific version information for affected or updated releases is not available. The project was informed of the problem early through an issue report but has not responded yet. |
| Concrete CMS 9 through 9.5.2 did not validate a CSRF token in the orphaned block removal panel action (removeOrphanedBlocks). A remote attacker could craft a request that, when loaded by an authenticated user holding edit permission on the target page, deleted every block on that page's current version; blocks not aliased to another page or scrapbook entry were also removed from the global Blocks table and their block-type data table, permanently destroying the content. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 7.1 with vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N. Thanks Yonatan Drori from Tenzai for reporting. |
| Rallly before 4.15.0 contains an information disclosure vulnerability in the polls.get tRPC procedure that returns scheduled-event invitee names and email addresses to unauthenticated callers. Attackers can access a poll's urlId from public invite links to retrieve sensitive invitee information regardless of privacy settings. |
| AVideo through revision c3edcc274c389816d434acadac07ee78eaf330c1 (master, 2026-08-23) incompletely sanitizes sensitive user fields in the APIName=video response. Video rows include columns joined from the video owner's user record, and API::get_api_video() calls removeSensitiveUserFields() only when the caller is neither authenticated nor using a valid API secret; it never compares User::getId() with the row's users_id. As a result, any low-privilege authenticated account can request another user's video and receive the owner's email address, account name (user), and isAdmin, canUpload and canStream flags, which are removed for guests and should be returned only to the owner or to callers with a valid API secret. No patched version was available at the time of the advisory. |
| WWBN AVideo through commit c3edcc274c389816d434acadac07ee78eaf330c1 contains a cross-site request forgery vulnerability in the LoginControl plugin PGP key endpoints that lack CSRF token validation. Attackers can craft malicious pages with image tags pointing to savePublicKey.json.php to replace a logged-in victim's PGP 2FA public key, causing lockout or enabling account takeover if the attacker knows the password. |
| Multiple vulnerabilities in Cisco IOS XE Software of could allow an authenticated, local attacker with level-15 privileges or an unauthenticated attacker with physical access to the device to execute persistent code at boot time and break the chain of trust.
These vulnerabilities are due path traversal and improper image integrity validation. A successful exploit could allow the attacker to execute persistent code on the underlying operating system.
Because this allows the attacker to bypass a major security feature of the device, Cisco has raised the Security Impact Rating (SIR) of this advisory from Medium to High.
For more information about these vulnerabilities, see the Details ["#details"] section of this advisory.
ERP |
| Concrete CMS below 9.5.3 was vulnerable to Cross-Site Request Forgery in the dashboard SEO Excluded Words page. The reset() controller action cleared the administrator-configured reserved-word list (concrete.seo.exclude_words) but did not validate the anti-CSRF token that the reset modal emitted, and it did not restrict the request to the POST method. A remote attacker who lured an authenticated user with SEO access to a crafted page could revert the reserved-word list to its default and silently alter future URL-slug generation for pages, files, topics, and other objects created through the Text urlify service, undoing the site's configured SEO slug policy. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.3 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks riodrwn for reporting. |
| Concrete CMS below 9.5.3 did not validate an anti-CSRF token on the block-arrangement backend endpoint (the arrange() action of Concrete\Controller\Backend\Page\ArrangeBlocks). The action enforced page-edit authorization but performed no token check, and its route accepted any HTTP method, so an attacker could induce a signed-in content editor into loading an attacker-controlled page that auto-submitted a cross-site request and reordered or moved blocks in the draft version of a page the victim was permitted to edit. The default null cookie SameSite configuration let the victim's session cookie accompany the forged request. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.3 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Yonatan Drori from Tenzai for reporting. |
