| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An inefficient regular expression complexity issue in the in-memory query evaluation component of the Mongoid library may allow an unauthenticated party to cause excessive processing within an embedding application process. Applications that place user-supplied text into a pattern-matching query condition on an embedded association may become unresponsive. |
| IBM WebSphere Application Server 9.0 and 8.5 is affected by a log injection vulnerability through crafted LTPA token cookies. |
| Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1225. |
| Use After Free in GitHub repository vim/vim prior to 9.0.0530. |
| Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1189. |
| In get_eht_operation_channel_width of ieee802_11_common.c, there is a possible out of bounds read due to an incorrect bounds check. This could lead to remote (proximal/adjacent) information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In multiple locations, there is a possible memory safety issue due to a heap buffer overflow. This could lead to remote code execution with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In multiple locations, there is a possible out of bounds write due to an integer overflow. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In parseParts of PduParser.java, there is a possible out of bounds read due to a heap buffer overflow. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| Stack-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.0577. |
| Out-of-bounds Read in GitHub repository vim/vim prior to 9.0.1143. |
| Heap based buffer overflow in vim/vim 9.0.0946 and below by allowing an attacker to CTRL-W gf in the expression used in the RHS of the substitute command. |
| Use After Free in GitHub repository vim/vim prior to 9.0.0579. |
| Stack-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.0598. |
| Heap-based buffer overflow in Microsoft Windows Media Foundation allows an unauthorized attacker to execute code over a network. |
| In a2dp_vendor_opus_decoder_decode_packet of a2dp_vendor_opus_decoder.cc, there is a possible out of bounds write due to a heap buffer overflow. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In convertCleanApertureToRect of HeifCleanAperture.cpp, there is a possible way to cause a temporary denial of service due to an integer overflow. This could lead to remote denial of service with no additional execution privileges needed. User interaction is not needed for exploitation. |
| A flaw was found in the automation-controller input-validation
guard sanitize_jinja(). The function uses two regular
expressions to reject user-supplied Jinja, but the patterns
stop at the first interior '}' or '%' character, so a Jinja
expression containing an inner brace (for example an empty
dict) is accepted while remaining valid Jinja. Because
sanitize_jinja() is the sole guard on several launch-time
fields — ad-hoc command module_args, Machine-credential
username / become_method / become_user, and inventory host
names — a low-privileged user can inject Jinja that ansible-core
evaluates in the execution environment. This enables execution
of arbitrary commands in the execution environment (bypassing an
administrator's AD_HOC_COMMANDS module allowlist) and disclosure
of secrets belonging to credentials the attacker cannot read
(by templating a co-attached credential's injected environment
variables), across the credential access-control boundary. |
| Out-of-bounds read vulnerability in the graphics module. Successful exploitation of this vulnerability may affect availability. |
| RabbitMQ is a messaging and streaming broker. Prior to versions 4.2.7 and 4.3.1, pattern_to_regex maps % -> .*? and _ -> ., then compiles ^...$ with only [unicode]; re:run is called with only [{capture, none}] - no explicit match_limit. A pattern like %_%_..._%X becomes ^.*?..*?.....*?.X$ with overlapping lazy quantifiers. The whole-expression cap is ?MAX_EXPRESSION_LENGTH=4096 chars / ?MAX_TOKENS=200; a LIKE string literal is one token, so ~2000 %_ pairs fit. SQL filters are accepted unconditionally at rabbit_amqp_session.erl:3264 (no feature flag). Evaluated per-message at rabbit_stream_queue.erl:1439. OTP's default 10M match_limit caps each match at ~100-200 ms (not seconds), and the re NIF yields to the scheduler. An authenticated AMQP 1.0 consumer with read+write on a stream queue can cause ~100-200 ms of CPU per delivered message via a crafted LIKE filter, multiplied across thousands of messages and parallel sessions - a substantial backtracking-driven CPU amplification. Preconditions include AMQP 1.0 with stream queues in use Attacker can attach a receiver with a filter (read permission) and publish messages with long property values (write permission). This issue is fixed in versions 4.2.7 and 4.3.1. |
