A blind Server-Side Request Forgery (SSRF) vulnerability was found in Moodle. This flaw exists due to insufficient validation of user-supplied input in LTI provider library. The library does not utilise Moodle's inbuilt cURL helper, which resulted in a blind SSRF risk. An attacker can send a specially crafted HTTP request and trick the application to initiate requests to arbitrary systems. This vulnerability allows a remote attacker to perform SSRF attacks.
xterm before 375 allows code execution via font ops, e.g., because an OSC 50 response may have Ctrl-g and therefore lead to command execution within the vi line-editing mode of Zsh. NOTE: font ops are not allowed in the xterm default configurations of some Linux distributions.
An out-of-bounds (OOB) write flaw was found in Apache Commons BCEL API. This flaw can be used to produce arbitrary bytecode and may abuse applications that pass attacker-controlled data to those APIs, giving the attacker more control over the resulting bytecode than otherwise expected.
A limited SQL injection risk was identified in the "browse list of users" site administration page.
An attacker who submits a crafted tar file with size in header struct being 0 may be able to trigger an calling of malloc(0) for a variable gnulonglink, causing an out-of-bounds read.
A security vulnerability was found in zlib. The flaw triggered a heap-based buffer in inflate in the inflate.c function via a large gzip header extra field. This flaw is only applicable in the call inflateGetHeader.
sqclass.cpp in Squirrel through 2.2.5 and 3.x through 3.1 allows an out-of-bounds read (in the core interpreter) that can lead to Code Execution. If a victim executes an attacker-controlled squirrel script, it is possible for the attacker to break out of the squirrel script sandbox even if all dangerous functionality such as File System functions has been disabled. An attacker might abuse this bug to target (for example) Cloud services that allow customization via SquirrelScripts, or distribute malware through video games that embed a Squirrel Engine.
An omitted execution parameter resulted in a remote code execution risk for sites running GhostScript versions older than 9.50.
Versions affected: 4.0 to 4.0.1, 3.11 to 3.11.7, 3.9 to 3.9.14 and earlier unsupported versions Versions fixed: 4.0.2, 3.11.8 and 3.9.15
A vulnerability was found in curl. This issue occurs because when curl saves cookies, alt-svc, and HSTS data to local files, it makes the operation atomic by finalizing the process with a rename from a temporary name to the final target file name. This flaw leads to unpreserved file permissions, either by mistake or by a malicious actor.
A flaw was found in OpenSSL. The issue in CVE-2022-1292 did not find other places in the crehash script where it possibly passed the file names of certificates being hashed to a command executed through the shell. Some operating systems distribute this script in a manner where it is automatically executed. On these operating systems, this flaw allows an attacker to execute arbitrary commands with the privileges of the script.
A flaw was found in the modproxy module of httpd. The server may remove the X-Forwarded- headers from a request based on the client-side Connection header hop-by-hop mechanism.
An out-of-bounds read vulnerability was found in httpd. A very large input to the apstrcmpmatch function can lead to an integer overflow and result in an out-of-bounds read.
jmespath.rb (aka JMESPath for Ruby) before 1.6.1 uses JSON.load in a situation where JSON.parse is preferable.
A flaw was found in CORS Filter feature from the go-restful package. When a user inputs a domain which is in AllowedDomains, all domains starting with the same pattern are accepted. This issue could allow an attacker to break the CORS policy by allowing any page to make requests and retrieve data on behalf of users.
A flaw was found in moodle where logic used to count failed login attempts could result in the account lockout threshold being bypassed.
A flaw was found in OpenSSL. The crehash script does not properly sanitize shell meta-characters to prevent command injection. Some operating systems distribute this script in a manner where it is automatically executed. This flaw allows an attacker to execute arbitrary commands with the privileges of the script on these operating systems.
An out-of-bounds read/write vulnerability was found in the modsed module of httpd. This flaw allows an attacker to overwrite the memory of an httpd instance that is using modsed with data provided by the attacker.
A flaw was found in httpd. The inbound connection is not closed when it fails to discard the request body, which may expose the server to HTTP request smuggling.
A flaw was found in httpd, where it incorrectly limits the value of the LimitXMLRequestBody option. This issue can lead to an integer overflow and later causes an out-of-bounds write.
An integer overflow was found in expat. The issue occurs in storeRawNames() by abusing the mbuffer expansion logic to allow allocations very close to INTMAX and out-of-bounds heap writes. This flaw can cause a denial of service or potentially arbitrary code execution.
A flaw was found in expat. Passing malformed 2- and 3-byte UTF-8 sequences (for example, from start tag names) to the XML processing application on top of expat can lead to arbitrary code execution. This issue is dependent on how invalid UTF-8 is handled inside the XML processor.
pgjdbc is the offical PostgreSQL JDBC Driver. A security hole was found in the jdbc driver for postgresql database while doing security research. The system using the postgresql library will be attacked when attacker control the jdbc url or properties. pgjdbc instantiates plugin instances based on class names provided via authenticationPluginClassName, sslhostnameverifier, socketFactory, sslfactory, sslpasswordcallback connection properties. However, the driver did not verify if the class implements the expected interface before instantiating the class. This can lead to code execution loaded via arbitrary classes. Users using plugins are advised to upgrade. There are no known workarounds for this issue.
A remote stack overflow in the TIPC networking module. With FORTIFYSOURCE's stricter memcpy() bounds checking, this can be exploited to cause remote DOS via kernel panic on systems using TIPC. Prior to these bounds checks, and with a canary leak (or no CONFIGSTACKPROTECTOR), this can be exploited for RCE.
Reference: https://www.openwall.com/lists/oss-security/2022/02/10/1
Last updated 4 March 2025
Last updated 4 March 2025
A buffer overflow flaw in httpd's lua module could allow an out-of-bounds write. An attacker who is able to submit a crafted request to an httpd instance that is using the lua module may be able to cause an impact to confidentiality, integrity, and/or availability.
Impact
The fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allow attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a remote code execution (RCE) attack.
Affected packages Only the org.apache.logging.log4j:log4j-core package is directly affected by this vulnerability. The org.apache.logging.log4j:log4j-api should be kept at the same version as the org.apache.logging.log4j:log4j-core package to ensure compatability if in use.
Mitigation
Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. This issue can be mitigated in prior releases (< 2.16.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).
Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default. Note that previous mitigations involving configuration such as to set the system property log4j2.formatMsgNoLookups to true do NOT mitigate this specific vulnerability.
Apache Log4j <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled (CVE-2021-44228).
Summary
Log4j versions prior to 2.16.0 are subject to a remote code execution vulnerability via the ldap JNDI parser. As per Apache's Log4j security guide: Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.16.0, this behavior has been disabled by default.
Log4j version 2.15.0 contained an earlier fix for the vulnerability, but that patch did not disable attacker-controlled JNDI lookups in all situations. For more information, see the Updated advice for version 2.16.0 section of this advisory.
Impact
Logging untrusted or user controlled data with a vulnerable version of Log4J may result in Remote Code Execution (RCE) against your application. This includes untrusted data included in logged errors such as exception traces, authentication failures, and other unexpected vectors of user controlled input.
Affected versions
Any Log4J version prior to v2.15.0 is affected to this specific issue.
The v1 branch of Log4J which is considered End Of Life (EOL) is vulnerable to other RCE vectors so the recommendation is to still update to 2.16.0 where possible.
Security releases Additional backports of this fix have been made available in versions 2.3.1, 2.12.2, and 2.12.3
Affected packages Only the org.apache.logging.log4j:log4j-core package is directly affected by this vulnerability. The org.apache.logging.log4j:log4j-api should be kept at the same version as the org.apache.logging.log4j:log4j-core package to ensure compatability if in use.
Remediation Advice
Updated advice for version 2.16.0
The Apache Logging Services team provided updated mitigation advice upon the release of version 2.16.0, which disables JNDI by default and completely removes support for message lookups. Even in version 2.15.0, lookups used in layouts to provide specific pieces of context information will still recursively resolve, possibly triggering JNDI lookups. This problem is being tracked as CVE-2021-45046. More information is available on the GitHub Security Advisory for CVE-2021-45046.
Users who want to avoid attacker-controlled JNDI lookups but cannot upgrade to 2.16.0 must ensure that no such lookups resolve to attacker-provided data and ensure that the the JndiLookup class is not loaded.
Please note that Log4J v1 is End Of Life (EOL) and will not receive patches for this issue. Log4J v1 is also vulnerable to other RCE vectors and we recommend you migrate to Log4J 2.16.0 where possible.
A buffer overrun vulnerability was discovered in CGI.escapehtml. This can lead to a buffer overflow when a user passes a very large string (> 700 MB) to CGI.escapehtml on a platform where long type takes 4 bytes, typically, Windows.