| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Issue summary: Generating excessively long X9.42 DH keys or checking
excessively long X9.42 DH keys or parameters may be very slow.
Impact summary: Applications that use the functions DH_generate_key() to
generate an X9.42 DH key may experience long delays. Likewise, applications
that use DH_check_pub_key(), DH_check_pub_key_ex() or EVP_PKEY_public_check()
to check an X9.42 DH key or X9.42 DH parameters may experience long delays.
Where the key or parameters that are being checked have been obtained from
an untrusted source this may lead to a Denial of Service.
While DH_check() performs all the necessary checks (as of CVE-2023-3817),
DH_check_pub_key() doesn't make any of these checks, and is therefore
vulnerable for excessively large P and Q parameters.
Likewise, while DH_generate_key() performs a check for an excessively large
P, it doesn't check for an excessively large Q.
An application that calls DH_generate_key() or DH_check_pub_key() and
supplies a key or parameters obtained from an untrusted source could be
vulnerable to a Denial of Service attack.
DH_generate_key() and DH_check_pub_key() are also called by a number of
other OpenSSL functions. An application calling any of those other
functions may similarly be affected. The other functions affected by this
are DH_check_pub_key_ex(), EVP_PKEY_public_check(), and EVP_PKEY_generate().
Also vulnerable are the OpenSSL pkey command line application when using the
"-pubcheck" option, as well as the OpenSSL genpkey command line application.
The OpenSSL SSL/TLS implementation is not affected by this issue.
The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue. |
| Issue summary: A bug has been identified in the processing of key and
initialisation vector (IV) lengths. This can lead to potential truncation
or overruns during the initialisation of some symmetric ciphers.
Impact summary: A truncation in the IV can result in non-uniqueness,
which could result in loss of confidentiality for some cipher modes.
When calling EVP_EncryptInit_ex2(), EVP_DecryptInit_ex2() or
EVP_CipherInit_ex2() the provided OSSL_PARAM array is processed after
the key and IV have been established. Any alterations to the key length,
via the "keylen" parameter or the IV length, via the "ivlen" parameter,
within the OSSL_PARAM array will not take effect as intended, potentially
causing truncation or overreading of these values. The following ciphers
and cipher modes are impacted: RC2, RC4, RC5, CCM, GCM and OCB.
For the CCM, GCM and OCB cipher modes, truncation of the IV can result in
loss of confidentiality. For example, when following NIST's SP 800-38D
section 8.2.1 guidance for constructing a deterministic IV for AES in
GCM mode, truncation of the counter portion could lead to IV reuse.
Both truncations and overruns of the key and overruns of the IV will
produce incorrect results and could, in some cases, trigger a memory
exception. However, these issues are not currently assessed as security
critical.
Changing the key and/or IV lengths is not considered to be a common operation
and the vulnerable API was recently introduced. Furthermore it is likely that
application developers will have spotted this problem during testing since
decryption would fail unless both peers in the communication were similarly
vulnerable. For these reasons we expect the probability of an application being
vulnerable to this to be quite low. However if an application is vulnerable then
this issue is considered very serious. For these reasons we have assessed this
issue as Moderate severity overall.
The OpenSSL SSL/TLS implementation is not affected by this issue.
The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this because
the issue lies outside of the FIPS provider boundary.
OpenSSL 3.1 and 3.0 are vulnerable to this issue. |
| A crafted self-referential DOS partition table will cause all Das U-Boot versions through 2019.07-rc4 to infinitely recurse, causing the stack to grow infinitely and eventually either crash or overwrite other data. |
| An insufficient session expiration vulnerability [CWE-613] vulnerability in Fortinet FortiOS 7.4.0, FortiOS 7.2 all versions, FortiOS 7.0 all versions, FortiOS 6.4 all versions allows attacker to maintain access to network resources via an active SSLVPN session not terminated after a user's password change under particular conditions outside of the attacker's control |
| HireFlow v1.2 is vulnerable to Incorrect Access Control. The application does not enforce object-level authorization on the /candidate/<id> and /interview/<id> endpoints. The route handlers retrieve records by the user-supplied ID without verifying that the requesting user is the owner or has an authorized role. Any authenticated user can access any other user's candidate profiles and interview notes by iterating the integer ID in the URL path, constituting a horizontal privilege escalation and full data breach of all records in the system. |
| In Meari IoT Cloud MQTT Broker deployments running EMQX 4.x, any authenticated low-privilege account can subscribe to global wildcard topics and receive telemetry from devices the user does not own. The broker enforces publish restrictions but does not enforce equivalent subscribe authorization at per-device scope. |
| @workos/authkit-session is a toolkit for building WorkOS AuthKit framework integrations. Prior to 0.5.1, an open redirect vulnerability exists in AuthService.handleCallback due to insufficient validation of the returnPathname value derived from the OAuth state parameter. The state parameter is round-tripped through the identity provider (IdP) and can be influenced by an attacker. The handleCallback function decodes and returns returnPathname without enforcing restrictions on origin or scheme. As a result, attacker-controlled values may be returned to the application. If this value is used directly in a redirect, it may cause the user to be redirected to an external, attacker-controlled site. This vulnerability is fixed in 0.5.1. |
| Symbolic-link path traversal (CWE-61, CWE-22) in pgAdmin 4 File Manager.
check_access_permission used os.path.abspath, which resolves '..' but does not resolve symbolic links, while the subsequent kernel write follows symlinks. An authenticated user could plant a symbolic link inside their own storage directory pointing outside it and induce pgAdmin to write to any path reachable by the pgAdmin process.
Fix switches the access check to os.path.realpath for both source and destination, and adds an _open_upload_target helper that opens the target with O_NOFOLLOW (mode 0o600) to close the leaf-component TOCTOU between the access check and the open. File mode is hardened from 0o644 to 0o600.
This issue affects pgAdmin 4: before 9.15. |
| A vulnerability has been identified in SIMATIC Field PG M5 (All versions), SIMATIC Field PG M6 (All versions < V26.01.12), SIMATIC IPC BX-21A (All versions < V31.01.07), SIMATIC IPC BX-32A (All versions < V29.01.07), SIMATIC IPC BX-39A (All versions < V29.01.07), SIMATIC IPC BX-59A (All versions < V32.01.04), SIMATIC IPC PX-32A (All versions < V29.01.07), SIMATIC IPC PX-39A (All versions < V29.01.07), SIMATIC IPC PX-39A PRO (All versions < V29.01.07), SIMATIC IPC RC-543A (All versions < V36.01.03), SIMATIC IPC RC-543B (All versions < V35.01.12), SIMATIC IPC RW-543A (All versions < V1.1.4), SIMATIC IPC RW-543B (All versions < V35.02.10), SIMATIC IPC127E (All versions < V27.01.11), SIMATIC IPC227E (All versions), SIMATIC IPC227G (All versions < V28.01.14), SIMATIC IPC277E (All versions), SIMATIC IPC277G (All versions < V28.01.14), SIMATIC IPC277G PRO (All versions < V28.01.14), SIMATIC IPC3000 SMART V3 (All versions), SIMATIC IPC327G (All versions < V28.01.14), SIMATIC IPC347G (All versions), SIMATIC IPC377G (All versions < V28.01.14), SIMATIC IPC427E (All versions), SIMATIC IPC477E (All versions), SIMATIC IPC477E PRO (All versions), SIMATIC IPC527G (All versions), SIMATIC IPC627E (All versions < V25.02.15), SIMATIC IPC647E (All versions < V25.02.15), SIMATIC IPC677E (All versions < V25.02.15), SIMATIC IPC847E (All versions < V25.02.15), SIMATIC ITP1000 (All versions). The affected devices have insufficient protection mechanism for the EFI(Extensible Firmware Interface) variables stored on the device. This could allow an authenticated attacker to disable the BIOS password without proper authorization by directly communicate with the flash controller. |
| A vulnerability has been identified in SIMATIC Field PG M5 (All versions), SIMATIC IPC BX-21A (All versions < V31.01.07), SIMATIC IPC BX-32A (All versions < V29.01.07), SIMATIC IPC BX-39A (All versions < V29.01.07), SIMATIC IPC BX-59A (All versions < V32.01.04), SIMATIC IPC PX-32A (All versions < V29.01.07), SIMATIC IPC PX-39A (All versions < V29.01.07), SIMATIC IPC PX-39A PRO (All versions < V29.01.07), SIMATIC IPC RC-543A (All versions < V36.01.03), SIMATIC IPC RC-543B (All versions < V35.01.12), SIMATIC IPC RW-543A (All versions < V1.1.4), SIMATIC IPC RW-543B (All versions < V35.02.10), SIMATIC IPC127E (All versions < V27.01.11), SIMATIC IPC227E (All versions), SIMATIC IPC227G (All versions < V28.01.14), SIMATIC IPC277E (All versions), SIMATIC IPC277G (All versions < V28.01.14), SIMATIC IPC277G PRO (All versions < V28.01.14), SIMATIC IPC3000 SMART V3 (All versions), SIMATIC IPC327G (All versions < V28.01.14), SIMATIC IPC347G (All versions), SIMATIC IPC377G (All versions < V28.01.14), SIMATIC IPC427E (All versions), SIMATIC IPC477E (All versions), SIMATIC IPC477E PRO (All versions), SIMATIC IPC527G (All versions), SIMATIC IPC627E (All versions < V25.02.15), SIMATIC IPC647E (All versions < V25.02.15), SIMATIC IPC677E (All versions < V25.02.15), SIMATIC IPC847E (All versions < V25.02.15), SIMATIC ITP1000 (All versions). The affected devices have insufficient protection mechanism for the EFI(Extensible Firmware Interface) variables stored on the device. This could allow an authenticated attacker to alter the secure boot configuration without proper authorization by directly communicate with the flash controller. |
| Net::IMAP implements Internet Message Access Protocol (IMAP) client functionality in Ruby. Prior to versions 0.3.10, 0.4.24, 0.5.14, and 0.6.4, a man-in-the-middle attacker can cause Net::IMAP#starttls to return "successfully", without starting TLS. This issue has been patched in versions 0.3.10, 0.4.24, 0.5.14, and 0.6.4. |
| The LatePoint plugin for WordPress is vulnerable to Account Takeover via Weak Password Recovery Mechanism in the unauthenticated guest booking flow in versions up to, and including, 5.5.0 This is due to the save_connected_wordpress_user() function propagating a LatePoint customer's email address to its linked WordPress user account via wp_update_user() without any ownership verification, combined with the guest booking flow's ability to overwrite an existing customer's email through phone-based merge without authentication. This makes it possible for unauthenticated attackers to overwrite the email address of a non-super-admin WordPress user account that is not yet linked to a LatePoint customer, enabling full account takeover by subsequently triggering the standard WordPress password-reset flow to the attacker-controlled address granted the plugin is configured with WordPress user integration enabled, phone-based contact merging, and customer authentication disabled. Administrator accounts on single-site installs are not affected. |
| Vaultwarden is a Bitwarden-compatible server written in Rust. Prior to 1.35.5, refresh tokens are not invalidated when the user's security_stamp is rotated by some security-sensitive operations (password change, KDF change, key rotation, email change, org admin password reset, emergency access takeover). This allows an attacker holding a previously obtained refresh token to maintain session access even after the user has taken action to secure their account. This vulnerability is fixed in 1.35.5. |
| WWBN AVideo is an open source video platform. In versions up to and including 29.0, plugin/PayPalYPT/agreementCancel.json.php cancels a PayPal billing agreement using an attacker-supplied agreement parameter without verifying that the authenticated user owns the agreement. A low-privilege authenticated user who learns or obtains another user's PayPal billing agreement ID can silently suspend the victim's recurring subscription, causing revenue loss to the platform and loss of paid service to the victim. Commit 0da3dcff1eda2f497694bf82b559829471c292c2 contains an updated fix. |
| Alkacon OpenCms before 16 allows XXE when the <!DOCTYPE> refers to an external host. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: typec: displayport: Fix potential deadlock
The deadlock can occur due to a recursive lock acquisition of
`cros_typec_altmode_data::mutex`.
The call chain is as follows:
1. cros_typec_altmode_work() acquires the mutex
2. typec_altmode_vdm() -> dp_altmode_vdm() ->
3. typec_altmode_exit() -> cros_typec_altmode_exit()
4. cros_typec_altmode_exit() attempts to acquire the mutex again
To prevent this, defer the `typec_altmode_exit()` call by scheduling
it rather than calling it directly from within the mutex-protected
context. |
| Vulnerability in Wikimedia Foundation MediaWiki.
This vulnerability is associated with program files includes/Page/Article.Php.
This issue affects MediaWiki: from * before 1.43.7, 1.44.4, 1.45.2. |
| In the Linux kernel, the following vulnerability has been resolved:
bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock
There are multiple places from where the recovery work gets scheduled
asynchronously. Also, there are multiple places where the caller waits
synchronously for the recovery to be completed. One such place is during
the PM shutdown() callback.
If the device is not alive during recovery_work, it will try to reset the
device using pci_reset_function(). This function internally will take the
device_lock() first before resetting the device. By this time, if the lock
has already been acquired, then recovery_work will get stalled while
waiting for the lock. And if the lock was already acquired by the caller
which waits for the recovery_work to be completed, it will lead to
deadlock.
This is what happened on the X1E80100 CRD device when the device died
before shutdown() callback. Driver core calls the driver's shutdown()
callback while holding the device_lock() leading to deadlock.
And this deadlock scenario can occur on other paths as well, like during
the PM suspend() callback, where the driver core would hold the
device_lock() before calling driver's suspend() callback. And if the
recovery_work was already started, it could lead to deadlock. This is also
observed on the X1E80100 CRD.
So to fix both issues, use pci_try_reset_function() in recovery_work. This
function first checks for the availability of the device_lock() before
trying to reset the device. If the lock is available, it will acquire it
and reset the device. Otherwise, it will return -EAGAIN. If that happens,
recovery_work will fail with the error message "Recovery failed" as not
much could be done. |
| In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Set hugetlb mmap base address aligned with pmd size
With ltp test case "testcases/bin/hugefork02", there is a dmesg error
report message such as:
kernel BUG at mm/hugetlb.c:5550!
Oops - BUG[#1]:
CPU: 0 UID: 0 PID: 1517 Comm: hugefork02 Not tainted 6.14.0-rc2+ #241
Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
pc 90000000004eaf1c ra 9000000000485538 tp 900000010edbc000 sp 900000010edbf940
a0 900000010edbfb00 a1 9000000108d20280 a2 00007fffe9474000 a3 00007ffff3474000
a4 0000000000000000 a5 0000000000000003 a6 00000000003cadd3 a7 0000000000000000
t0 0000000001ffffff t1 0000000001474000 t2 900000010ecd7900 t3 00007fffe9474000
t4 00007fffe9474000 t5 0000000000000040 t6 900000010edbfb00 t7 0000000000000001
t8 0000000000000005 u0 90000000004849d0 s9 900000010edbfa00 s0 9000000108d20280
s1 00007fffe9474000 s2 0000000002000000 s3 9000000108d20280 s4 9000000002b38b10
s5 900000010edbfb00 s6 00007ffff3474000 s7 0000000000000406 s8 900000010edbfa08
ra: 9000000000485538 unmap_vmas+0x130/0x218
ERA: 90000000004eaf1c __unmap_hugepage_range+0x6f4/0x7d0
PRMD: 00000004 (PPLV0 +PIE -PWE)
EUEN: 00000007 (+FPE +SXE +ASXE -BTE)
ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0)
PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
Process hugefork02 (pid: 1517, threadinfo=00000000a670eaf4, task=000000007a95fc64)
Call Trace:
[<90000000004eaf1c>] __unmap_hugepage_range+0x6f4/0x7d0
[<9000000000485534>] unmap_vmas+0x12c/0x218
[<9000000000494068>] exit_mmap+0xe0/0x308
[<900000000025fdc4>] mmput+0x74/0x180
[<900000000026a284>] do_exit+0x294/0x898
[<900000000026aa30>] do_group_exit+0x30/0x98
[<900000000027bed4>] get_signal+0x83c/0x868
[<90000000002457b4>] arch_do_signal_or_restart+0x54/0xfa0
[<90000000015795e8>] irqentry_exit_to_user_mode+0xb8/0x138
[<90000000002572d0>] tlb_do_page_fault_1+0x114/0x1b4
The problem is that base address allocated from hugetlbfs is not aligned
with pmd size. Here add a checking for hugetlbfs and align base address
with pmd size. After this patch the test case "testcases/bin/hugefork02"
passes to run.
This is similar to the commit 7f24cbc9c4d42db8a3c8484d1 ("mm/mmap: teach
generic_get_unmapped_area{_topdown} to handle hugetlb mappings"). |
| In the Linux kernel, the following vulnerability has been resolved:
block: mark GFP_NOIO around sysfs ->store()
sysfs ->store is called with queue freezed, meantime we have several
->store() callbacks(update_nr_requests, wbt, scheduler) to allocate
memory with GFP_KERNEL which may run into direct reclaim code path,
then potential deadlock can be caused.
Fix the issue by marking NOIO around sysfs ->store() |
