| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Vulnerability in the Oracle Work in Process product of Oracle E-Business Suite (component: Internal Operations). Supported versions that are affected are 12.2.5-12.2.15. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Work in Process. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Work in Process, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Work in Process accessible data as well as unauthorized read access to a subset of Oracle Work in Process accessible data. CVSS 3.1 Base Score 5.4 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N). |
| Vulnerability in the Oracle Banking Trade Finance Process Management product of Oracle Financial Services Applications (component: Common). Supported versions that are affected are 14.6.0-14.8.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Banking Trade Finance Process Management. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Banking Trade Finance Process Management, 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 Banking Trade Finance Process Management accessible data as well as unauthorized access to critical data or complete access to all Oracle Banking Trade Finance Process Management accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Banking Trade Finance Process Management. CVSS 3.1 Base Score 9.6 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:L). |
| Inappropriate implementation in ScriptInjections in Google Chrome on iOS prior to 150.0.7871.47 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
| Unauthenticated Cross Site Request Forgery (CSRF) in Simple Link Directory Pro <= 15.0.8 versions. |
| Cross-Site Request Forgery (CSRF) vulnerability in MailPoet allows Cross Site Request Forgery.
This issue affects MailPoet: from 5.30.0 through 5.33.0. |
| Unauthenticated Cross Site Request Forgery (CSRF) in Ninja Forms File Uploads Extension <= 3.3.26 versions. |
| Unauthenticated Cross Site Request Forgery (CSRF) in WP Activity Log <= 5.6.4 versions. |
| Unauthenticated Cross Site Request Forgery (CSRF) in Zarinpal Gateway <= 5.1.0 versions. |
| Vulnerability in the Oracle Enterprise Manager Base Platform product of Oracle Enterprise Manager (component: Security Framework). The supported version that is affected is 24.1. Easily exploitable vulnerability allows low privileged attacker with network access via HTTPS to compromise Oracle Enterprise Manager Base Platform. 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 Oracle Enterprise Manager Base Platform accessible data. CVSS 3.1 Base Score 3.5 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N). |
| Unauthenticated Cross Site Request Forgery (CSRF) in WP Accessibility Helper (WAH) <= 0.6.6 versions. |
| Unauthenticated Cross Site Request Forgery (CSRF) in LA-Studio Element Kit for Elementor <= 1.6.2 versions. |
| Cross Site Request Forgery vulnerability in andreimarcu linux-server v.1.0 through v.2.3.8 allows a remote attacker to execute arbitrary code via the uploadPutHandler function |
| A Cross-Site Request Forgery (CSRF) vulnerability exists in the xxl-job-admin web application v.3.0.0 that allows an attacker to perform unauthorized modifications to Glue IDE shell scripts. The affected endpoint lacks proper CSRF token validation and accepts arbitrary HTTP methods via a permissive request mapping |
| Missing validation of the outer content_type byte on TLS 1.3 encrypted records in s2n-tls allows an active man-in-the-middle to silently discard individual application data records without either endpoint detecting the modification. RFC 8446 Section 5.2 requires that the outer content_type of all encrypted TLS 1.3 records must be application_data (0x17). The s2n-tls AEAD implementation hardcodes this value in the additional authenticated data rather than using the actual wire byte, so the outer content_type is not covered by the authentication tag.
This enables selective suppression of application data. In HTTP pipelining scenarios, dropping a TLS record containing an HTTP request can cause request/response desynchronization, where subsequent responses are delivered to the wrong requests. In write-heavy workloads, a dropped record containing a write request can result in undetectable data loss when the client interprets a subsequent success response as confirmation of the dropped write.
All TLS 1.3 connections are affected. Both TLS clients and servers are affected. TLS 1.2 and QUIC connections are not affected.
We recommend you upgrade s2n-tls to version v1.7.6 |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix lock leak on ENOMEM in AMDGPU_GEM_OP_GET_MAPPING_INFO
The AMDGPU_GEM_OP_GET_MAPPING_INFO branch of amdgpu_gem_op_ioctl()
holds three cleanup-tracked resources before calling kvcalloc():
the drm_gem_object reference from drm_gem_object_lookup(), the
drm_exec lock on the looked-up GEM via drm_exec_lock_obj(), and
the drm_exec lock on the per-process VM root page directory via
amdgpu_vm_lock_pd(). All three are released by the out_exec
label that every other error path in this function jumps to.
The kvcalloc() failure path returns -ENOMEM directly, skipping
out_exec and leaking all three.
The leaked per-process VM root PD dma_resv lock is the
load-bearing leak: any subsequent operation on the same VM
(further GEM ops, command-submission, eviction, TTM shrinker
callbacks) blocks on the held lock. DRM_IOCTL_AMDGPU_GEM_OP is
DRM_AUTH | DRM_RENDER_ALLOW, so this is an unprivileged-local
denial of service against the caller's GPU context, reachable
by any process with /dev/dri/renderD* access.
Route the failure through out_exec so drm_exec_fini() and
drm_gem_object_put() run.
Reproduced on stock 7.0.0-10, Ryzen 7 5700U / Radeon Vega
(Lucienne): the failing ioctl returns -ENOMEM and a second
GET_MAPPING_INFO on the same fd then blocks in
drm_exec_lock_obj() on the leaked dma_resv. SIGKILL on the
caller does not reap the task; the fd-release path during
process exit goes through amdgpu_gem_object_close() ->
drm_exec_prepare_obj() on the same lock, leaving the task in D
state until the box is rebooted. The patched kernel was not
rebuilt and re-tested on this hardware; the fix is mechanical.
Tested on a single Lucienne / Vega box only.
Ziyi Guo posted an independent INT_MAX-bound check for
args->num_entries in the same branch [1]; the two patches are
complementary and can land in either order.
(cherry picked from commit b69d3256d79de15f54c322986ff4da68f1d65b0a) |
| In NLnet Labs Unbound 1.6.0 up to and including 1.25.1, a replay of a wildcard rrset as another piece of data, could be briefly considered DNSSEC secure based only on the RRSIG validation and stored into cache, before later validation treats it as bogus based on NSEC validation. When the resolving thread puts secure on the rrset, and another thread that is on the serve expired path then picks up the updated rrset contents with the secure status for a reply, it can be used to change a specific record, next to a wildcard that could be covered by the wildcard, into the wildcard. A malicious actor can exploit the possible poisonous effect by having any DNSSEC-singed domain (irrelevant to the victim domain) and a CNAME wrapper record that points to a record next to a wildcard (that could be covered by the wildcard). Then quering Unbound for the wildcard sibling record would seed the secure message. A later (after expiry) query for the CNAME wrapper would need to resolve the target sibling record. If the wildcard replay is injected into the response, the wildcard rrset will update the expired sibling record with a secure status before completing proper wildcard validation with NSEC records and eventually treating the CNAME wrapper answer as bogus. The updated poisoned rrset is now secure and points to the wildcard. This vulnerability is explicit for the serve expired path and needs injection of the signed wildcard rrset without the NSEC accompanying rrset. |
| Inappropriate implementation in NFC in Google Chrome on Android prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
| Inappropriate implementation in PerformanceAPIs in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
| Inappropriate implementation in DevTools in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who convinced a user to engage in specific UI gestures to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
| Inappropriate implementation in SVG in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
