| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Obot before 0.26.0 contains an authentication bypass vulnerability in the CLI login flow that allows unauthenticated attackers to steal API keys by choosing token request IDs. Attackers can create a token request via POST /api/token-request, send the login link to a signed-in user, and fetch the resulting non-expiring API key to take over the victim's account. |
| Vulnerability in the Oracle Applications Framework product of Oracle E-Business Suite (component: Personalization). Supported versions that are affected are 12.2.3-12.2.15. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Applications Framework. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Applications Framework, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Applications Framework accessible data as well as unauthorized access to critical data or complete access to all Oracle Applications Framework accessible data. CVSS 3.1 Base Score 8.7 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N). |
| Roundcube Webmail before 1.6.20 and 1.7.x before 1.7.5 is affected by a CSRF validation bypass in the mark-as-junk action of the markasjunk plugin. The plugin read the _uid parameter from POST data but passed it to rcmail::get_uids() without constraining the input mode, so values re-read inside that helper could be taken from the query string and the action carried out without a valid CSRF token. Upstream fixed this in the commit “Fix CSRF validation bypass in the mark-as-junk action”, which passes rcube_utils::INPUT_POST explicitly. |
| Cross-Site Request Forgery (CSRF) vulnerability in Drupal Project Browser allows Cross Site Request Forgery. This issue affects Project Browser versions: from 0.0.0 to 2.0.3, from 2.1.0 to 2.1.5. |
| Cross-Site Request Forgery (CSRF) vulnerability in Drupal Tawk.to - Live chat application allows Cross Site Request Forgery. This issue affects Tawk.to - Live chat application versions: from 0.0.0 to 3.0.4. |
| Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to versions 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.6, Electron treated pages opened into a new window from links as application-initiated navigations instead of preserving the page containing the link as the initiator. The resulting top-level request could be classified as same-site, causing SameSite=Strict cookies to be sent and Sec-Fetch-Site not to identify the initiating page. An application that loads untrusted content and permits it to open new windows could therefore allow that content to make a credentialed request to another site that relies on SameSite cookies for CSRF protection. This issue is fixed in versions 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.6. |
| Vulnerability in the Siebel CRM End User product of Oracle Siebel CRM (component: Open UI). Supported versions that are affected are 17.0-26.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTP to compromise Siebel CRM End User. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Siebel CRM End User accessible data. CVSS 3.1 Base Score 3.1 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N). |
| In Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, an unauthenticated user could trick a user that holds a role with the edit_federated_providers capability into turning off all federated search providers. Successful exploitation could temporarily prevent federated searches from retrieving data from remote datasets.
The vulnerability is possible because the federated provider Representational State Transfer (REST) API accepts GET requests for actions that change provider state.
The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The unauthenticated user should not be able to exploit the vulnerability at will.
For more information see Run federated searches over remote Splunk platform deployments (https://help.splunk.com/en/splunk-enterprise/search/federated-search/10.6/run-federated-searches-across-other-splunk-deployments/run-federated-searches-over-remote-splunk-platform-deployments) and Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation. |
| Trigger.dev before 4.5.6 contains a cross-site request forgery vulnerability that allows remote attackers to log out authenticated users by sending a link to the GET-based /logout endpoint. Attackers can lure victims into clicking an obfuscated, URL-encoded link that terminates their session, causing loss of unsaved work. |
| Trigger.dev before 4.5.2 contains a cross-site request forgery vulnerability in the CLI authorization-code flow because loading /account/authorization-code/<code> mints a Personal Access Token without any consent step. Attackers mint an unauthenticated code, lure a logged-in user to that URL, then retrieve the victim's PAT from the unauthenticated /api/v1/token endpoint to take over the account. |
| The User Registration & Membership – Free & Paid Memberships, Subscriptions, Content Restriction, User Profile, Custom User Registration & Login Builder plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 5.2.8 This is due to missing or incorrect nonce validation on the trigger_bulk_action function. This makes it possible for unauthenticated attackers to force administrators to approve pending user registrations or deny arbitrary user accounts, locking targeted users out of the site via a forged request granted they can trick a site administrator into performing an action such as clicking on a link. An attacker can bypass the earlier nonce check in trigger_query_actions() by supplying an empty new_role parameter, which causes that handler to return early and cede control to the unprotected trigger_bulk_action() handler; the exit() call at the end of that handler additionally prevents WordPress core's own bulk-users nonce validation from executing. |
| Vulnerability in the Siebel Apps - Marketing product of Oracle Siebel CRM (component: Marketing). Supported versions that are affected are 17.0-26.9. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Siebel Apps - Marketing. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Siebel Apps - Marketing accessible data. CVSS 3.1 Base Score 4.3 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N). |
| Cross-Site Request Forgery (CSRF) vulnerability in Tailored Media Tailored Tools tailored-tools allows Cross Site Request Forgery.This issue affects Tailored Tools: from n/a through 3.0.3. |
| The Uncanny Toolkit for LearnDash WordPress plugin before 3.8.2 does not validate the origin of a password-reset request, allowing an unauthenticated attacker to set the password of a user who is partway through a password reset to an attacker-chosen value through a forged request, resulting in full account takeover. |
| The Patreon WordPress plugin before 1.10.0 does not verify a nonce when connecting the site to a Patreon account, allowing attackers to make a logged-in administrator re-link the integration to an attacker-controlled account via a crafted request (CSRF), taking over the site's Patreon integration. |
| Slims (Senayan Library Management Systems) 9 Bulian 9.8.0 allows cross-site request forgery (CSRF) against admin/modules/circulation/loan_history_maintenance.php because the action=run GET parameter performs privileged, destructive operations with no CSRF token or POST confirmation, leading to data loss of loan history records. |
| @fastify/oauth2 is a Fastify wrapper for OAuth2 login flows. In versions 7.2.0 through 8.3.1, the state and code-verifier cookies are set without a Path attribute at a login route with two or more path segments, while the clearing step at the OAuth callback writes them with a root path, so the original cookies survive the callback and the documented single-use guarantee for the state value does not hold. A state value an attacker learns stays valid for the rest of the browser session, letting the attacker drive their own authorization flow in the victim's browser and sign the victim in to the attacker's account (login CSRF). The issue is fixed in @fastify/oauth2 8.3.2, and users should upgrade to 8.3.2 or later. As a workaround, set an explicit cookie path so the set and the clear name the same cookie. |
| Cross-site request forgery in the REST API of Progressive Robot hMailServer 6.0.0 through 6.3.6 allows a remote attacker to make an authenticated user's browser perform a state-changing request. The REST API accepts HTTP Basic authentication and answers a browser with a Basic sign-in box; a browser caches the credential once the box is answered and sends it with later requests to that origin, including a top-level form post from another site, and the server reads a request body whatever its declared content type. The cross-site protection covered only the cookie session (a header a cross-site form cannot set, and a SameSite=Strict cookie); HTTP Basic was not held to it. A page under an attacker's control, visited by a user whose browser holds a cached Basic credential for the REST API - typically an administrator who signed in through the box - could therefore cause a state-changing request such as creating a domain, an account or an API key, or changing a setting, with the victim's credential. The attacker cannot read the cross-origin response, so the forgery is blind. |
| In the Linux kernel, the following vulnerability has been resolved:
sctp: add INIT verification after cookie unpacking
In SCTP handshake, the INIT chunk is initially processed by the server
and embedded into the cookie carried in INIT-ACK. The client then
returns this cookie via COOKIE-ECHO, where the server unpacks it and
reconstructs the original INIT chunk.
When cookie authentication is enabled, the cookie contents are protected
against tampering, so reusing the unpacked INIT without re-verification
is safe.
However, when cookie authentication is disabled, the reconstructed INIT
can no longer be trusted. In this case, the INIT must be explicitly
validated after unpacking to avoid processing potentially tampered data.
Add sctp_verify_init() checks after cookie unpacking in COOKIE-ECHO
processing paths (sctp_sf_do_5_1D_ce() and sctp_sf_do_5_2_4_dupcook())
when cookie_auth_enable is disabled. On failure, the new association is
freed and the packet is discarded.
Also tighten cookie validation in sctp_unpack_cookie() by verifying the
embedded chunk type is SCTP_CID_INIT before treating it as an INIT
chunk.
Finally, update sctp_verify_init() to validate parameter bounds using
the actual embedded INIT length instead of chunk->chunk_end, since the
INIT stored in COOKIE-ECHO may not span the entire chunk buffer. |
| 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. |
