Export limit exceeded: 12116 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 364491 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (364491 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-52003 | 1 Traefik | 1 Traefik | 2025-11-25 | 6.1 Medium |
| Traefik (pronounced traffic) is an HTTP reverse proxy and load balancer. There is a vulnerability in Traefik that allows the client to provide the X-Forwarded-Prefix header from an untrusted source. This issue has been addressed in versions 2.11.14 and 3.2.1. Users are advised to upgrade. There are no known workarounds for this vulnerability. | ||||
| CVE-2024-53477 | 1 Jflyfox | 1 Jfinal Cms | 2025-11-25 | 9.8 Critical |
| JFinal CMS 5.1.0 is vulnerable to Command Execution via unauthorized execution of deserialization in the file ApiForm.java | ||||
| CVE-2024-56140 | 2 Astro, Withastro | 2 Astro, Astro | 2025-11-25 | 5.9 Medium |
| Astro is a web framework for content-driven websites. In affected versions a bug in Astro’s CSRF-protection middleware allows requests to bypass CSRF checks. When the `security.checkOrigin` configuration option is set to `true`, Astro middleware will perform a CSRF check. However, a vulnerability exists that can bypass this security. A semicolon-delimited parameter is allowed after the type in `Content-Type`. Web browsers will treat a `Content-Type` such as `application/x-www-form-urlencoded; abc` as a `simple request` and will not perform preflight validation. In this case, CSRF is not blocked as expected. Additionally, the `Content-Type` header is not required for a request. This issue has been addressed in version 4.16.17 and all users are advised to upgrade. There are no known workarounds for this vulnerability. | ||||
| CVE-2024-56159 | 2 Astro, Withastro | 2 Astro, Astro | 2025-11-25 | 5.3 Medium |
| Astro is a web framework for content-driven websites. A bug in the build process allows any unauthenticated user to read parts of the server source code. During build, along with client assets such as css and font files, the sourcemap files **for the server code** are moved to a publicly-accessible folder. Any outside party can read them with an unauthorized HTTP GET request to the same server hosting the rest of the website. While some server files are hashed, making their access obscure, the files corresponding to the file system router (those in `src/pages`) are predictably named. For example. the sourcemap file for `src/pages/index.astro` gets named `dist/client/pages/index.astro.mjs.map`. This vulnerability is the root cause of issue #12703, which links to a simple stackblitz project demonstrating the vulnerability. Upon build, notice the contents of the `dist/client` (referred to as `config.build.client` in astro code) folder. All astro servers make the folder in question accessible to the public internet without any authentication. It contains `.map` files corresponding to the code that runs on the server. All **server-output** projects on Astro 5 versions **v5.0.3** through **v5.0.7**, that have **sourcemaps enabled**, either directly or through an add-on such as `sentry`, are affected. The fix for **server-output** projects was released in **astro@5.0.8**. Additionally, all **static-output** projects built using Astro 4 versions **4.16.17 or older**, or Astro 5 versions **5.0.8 or older**, that have **sourcemaps enabled** are also affected. The fix for **static-output** projects was released in **astro@5.0.9**, and backported to Astro v4 in **astro@4.16.18**. The immediate impact is limited to source code. Any secrets or environment variables are not exposed unless they are present verbatim in the source code. There is no immediate loss of integrity within the the vulnerable server. However, it is possible to subsequently discover another vulnerability via the revealed source code . There is no immediate impact to availability of the vulnerable server. However, the presence of an unsafe regular expression, for example, can quickly be exploited to subsequently compromise the availability. The fix for **server-output** projects was released in **astro@5.0.8**, and the fix for **static-output** projects was released in **astro@5.0.9** and backported to Astro v4 in **astro@4.16.18**. Users are advised to update immediately if they are using sourcemaps or an integration that enables sourcemaps. | ||||
| CVE-2024-40896 | 3 Netapp, Redhat, Xmlsoft | 15 H300s, H300s Firmware, H410c and 12 more | 2025-11-25 | 9.1 Critical |
| In libxml2 2.11 before 2.11.9, 2.12 before 2.12.9, and 2.13 before 2.13.3, the SAX parser can produce events for external entities even if custom SAX handlers try to override entity content (by setting "checked"). This makes classic XXE attacks possible. | ||||
| CVE-2025-66187 | 2025-11-25 | N/A | ||
| Not used | ||||
| CVE-2025-66186 | 2025-11-25 | N/A | ||
| Not used | ||||
| CVE-2025-66185 | 2025-11-25 | N/A | ||
| Not used | ||||
| CVE-2025-66184 | 2025-11-25 | N/A | ||
| Not used | ||||
| CVE-2025-66183 | 2025-11-25 | N/A | ||
| Not used | ||||
| CVE-2025-66182 | 2025-11-25 | N/A | ||
| Not used | ||||
| CVE-2025-66181 | 2025-11-25 | N/A | ||
| Not used | ||||
| CVE-2025-66180 | 2025-11-25 | N/A | ||
| Not used | ||||
| CVE-2025-66179 | 2025-11-25 | N/A | ||
| Not used | ||||
| CVE-2023-41419 | 2 Gevent, Redhat | 7 Gevent, Enterprise Linux, Openstack and 4 more | 2025-11-25 | 9.8 Critical |
| An issue in Gevent before version 23.9.0 allows a remote attacker to escalate privileges via a crafted script to the WSGIServer component. | ||||
| CVE-2023-53168 | 1 Linux | 1 Linux Kernel | 2025-11-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: usb: ucsi_acpi: Increase the command completion timeout Commit 130a96d698d7 ("usb: typec: ucsi: acpi: Increase command completion timeout value") increased the timeout from 5 seconds to 60 seconds due to issues related to alternate mode discovery. After the alternate mode discovery switch to polled mode the timeout was reduced, but instead of being set back to 5 seconds it was reduced to 1 second. This is causing problems when using a Lenovo ThinkPad X1 yoga gen7 connected over Type-C to a LG 27UL850-W (charging DP over Type-C). When the monitor is already connected at boot the following error is logged: "PPM init failed (-110)", /sys/class/typec is empty and on unplugging the NULL pointer deref fixed earlier in this series happens. When the monitor is connected after boot the following error is logged instead: "GET_CONNECTOR_STATUS failed (-110)". Setting the timeout back to 5 seconds fixes both cases. | ||||
| CVE-2023-53167 | 1 Linux | 1 Linux Kernel | 2025-11-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: tracing: Fix null pointer dereference in tracing_err_log_open() Fix an issue in function 'tracing_err_log_open'. The function doesn't call 'seq_open' if the file is opened only with write permissions, which results in 'file->private_data' being left as null. If we then use 'lseek' on that opened file, 'seq_lseek' dereferences 'file->private_data' in 'mutex_lock(&m->lock)', resulting in a kernel panic. Writing to this node requires root privileges, therefore this bug has very little security impact. Tracefs node: /sys/kernel/tracing/error_log Example Kernel panic: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038 Call trace: mutex_lock+0x30/0x110 seq_lseek+0x34/0xb8 __arm64_sys_lseek+0x6c/0xb8 invoke_syscall+0x58/0x13c el0_svc_common+0xc4/0x10c do_el0_svc+0x24/0x98 el0_svc+0x24/0x88 el0t_64_sync_handler+0x84/0xe4 el0t_64_sync+0x1b4/0x1b8 Code: d503201f aa0803e0 aa1f03e1 aa0103e9 (c8e97d02) ---[ end trace 561d1b49c12cf8a5 ]--- Kernel panic - not syncing: Oops: Fatal exception | ||||
| CVE-2023-53166 | 1 Linux | 1 Linux Kernel | 2025-11-24 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: power: supply: bq25890: Fix external_power_changed race bq25890_charger_external_power_changed() dereferences bq->charger, which gets sets in bq25890_power_supply_init() like this: bq->charger = devm_power_supply_register(bq->dev, &bq->desc, &psy_cfg); As soon as devm_power_supply_register() has called device_add() the external_power_changed callback can get called. So there is a window where bq25890_charger_external_power_changed() may get called while bq->charger has not been set yet leading to a NULL pointer dereference. This race hits during boot sometimes on a Lenovo Yoga Book 1 yb1-x90f when the cht_wcove_pwrsrc (extcon) power_supply is done with detecting the connected charger-type which happens to exactly hit the small window: BUG: kernel NULL pointer dereference, address: 0000000000000018 <snip> RIP: 0010:__power_supply_is_supplied_by+0xb/0xb0 <snip> Call Trace: <TASK> __power_supply_get_supplier_property+0x19/0x50 class_for_each_device+0xb1/0xe0 power_supply_get_property_from_supplier+0x2e/0x50 bq25890_charger_external_power_changed+0x38/0x1b0 [bq25890_charger] __power_supply_changed_work+0x30/0x40 class_for_each_device+0xb1/0xe0 power_supply_changed_work+0x5f/0xe0 <snip> Fixing this is easy. The external_power_changed callback gets passed the power_supply which will eventually get stored in bq->charger, so bq25890_charger_external_power_changed() can simply directly use the passed in psy argument which is always valid. | ||||
| CVE-2023-53165 | 1 Linux | 1 Linux Kernel | 2025-11-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: udf: Fix uninitialized array access for some pathnames For filenames that begin with . and are between 2 and 5 characters long, UDF charset conversion code would read uninitialized memory in the output buffer. The only practical impact is that the name may be prepended a "unification hash" when it is not actually needed but still it is good to fix this. | ||||
| CVE-2023-53164 | 1 Linux | 1 Linux Kernel | 2025-11-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: irqchip/ti-sci: Fix refcount leak in ti_sci_intr_irq_domain_probe of_irq_find_parent() returns a node pointer with refcount incremented, We should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak. | ||||