| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An authentication bypass in the DOM security processor in Apache WSS4J allows unauthenticated remote attackers to forge authenticated SOAP messages via a crafted unsigned SAML sender-vouches assertion containing an attacker-controlled key.
Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4, which fix this issue. |
| In the StAX streaming WS-SecurityPolicy validator, certain relative or unsupported XPath expressions can be converted into paths that never match the actual XML element path. A remote SOAP peer may therefore send a required element without the expected signature or encryption.
Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4, which fix this issue. |
| In the WSS4J streaming (StAX) code, a signature reference using the WS-Security STR-Transform leaves an internal "inside signed content" flag permanently set. The WS-SecurityPolicy enforcer uses that flag to decide whether an element needs checking, so it stops evaluating SignedParts and SignedElements for the rest of the message. A policy requiring the SOAP Body to be signed is then satisfied even when the Body carries no signature, removing the protection against XML Signature Wrapping. Signature verification itself is unaffected. The DOM code is not affected.
Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4 which fix this issue. |
| WSS4J EncryptedHeader child confusion could promote an attacker-controlled plaintext element as the decrypted header, leading to incorrect confidentiality coverage and possible policy bypass.
Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4, which fix this issue. |
| Apache Airflow's Teradata provider embedded cloud storage credentials directly into SQL statements. `S3ToTeradataOperator` and `AzureBlobStorageToTeradataOperator` interpolate the source bucket's credentials as plain string literals into the `CREATE MULTISET TABLE ... LOCATION` statement whenever the bucket is private and no `teradata_authorization_name` is configured — which is the default credential path for both operators. The statement is then logged and executed, so the credentials reach two places outside the operator's control.
The two operators expose different credentials through different channels, and deployments should check both. `S3ToTeradataOperator` takes its values from `s3_hook.get_credentials()`, which under an instance profile or IRSA returns runtime AWS credentials that were never registered with Airflow's secrets masker — and the STS session token is runtime-generated and therefore unmasked even when an AWS connection is configured. Those credentials appear **in the Airflow task log**, readable by any user with log-view permission on the Dag. `AzureBlobStorageToTeradataOperator` takes its storage account key from the connection, so the masker usually redacts the task-log copy; its exposure is the Teradata side. **Both** operators write the credentials into Teradata's DBQL query logs and live monitoring views, where Airflow's masking never applies and the values persist for that system's log retention period.
Affects deployments using either operator against a private bucket or container without a Teradata `AUTHORIZATION` object. Users are advised to upgrade to `apache-airflow-providers-teradata` `3.7.0` or later, which keeps the credential-bearing statement out of the Airflow task log. Upgrading does not remove the credentials from Teradata's query logs and monitoring views, which Airflow cannot redact: users should configure `teradata_authorization_name` with a Teradata `AUTHORIZATION` object so that credentials are never inlined, and should rotate any credentials previously used through the inline path. |
| Apache Airflow's Snowflake provider did not validate the connection's `account` and `region` fields before interpolating them into request URLs. The SQL API endpoint is built as `https://{account}.snowflakecomputing.com/api/v2/statements`, so an `account` value containing `/`, `?` or `#` demotes the intended domain to a path, query or fragment and leaves the attacker in control of the request host.
The provider sends that request with an `Authorization: Bearer` header carrying a JWT minted from the connection's private key, or the configured OAuth or programmatic access token. A user who can edit the Snowflake connection but cannot read its secrets — Airflow gives connection-configuration users write-only access to stored credentials, and a `private_key_file` lives on the worker rather than in the connection — can therefore cause a valid token for the account to be delivered to a host of their choosing and replay it against the genuine Snowflake endpoint. No Dag-authoring ability is required: the attacker edits the connection and waits for an existing Dag to use it. The same unvalidated value was also used to build the OAuth token-request URL and the Cortex Agent base URL.
Affects deployments where Snowflake connections are editable by users who are not trusted with the connection's credentials. Users are advised to upgrade to `apache-airflow-providers-snowflake` `6.18.0` or later, which rejects `account` and `region` values containing anything other than letters, digits, `.`, `_` and `-` in every URL the provider builds from them. |
| The Apache Airflow Teradata provider's compute-cluster example Dag declared every one of its Dag Params as unconstrained free text and templated them straight into the compute-cluster operators, which interpolate those values into Teradata DDL. A user who is permitted to trigger that Dag - a lower-trust role than the Dag author, and one that needs no Teradata credentials of its own - could therefore supply SQL fragments that execute under the connection the task runs as, and could additionally redirect the task at any other connection defined in the deployment, because the connection id was itself a free-text Param. Only deployments that run this example Dag, or a Dag copied from it, are affected; the provider's operator code is unchanged. Users of apache-airflow-providers-teradata are recommended to upgrade to version 3.7.0 or later, whose example constrains the Params to validated identifiers and a closed value set and removes connection selection and free-form option strings from trigger-time input. Upgrading does not change a Dag already copied from the example; users who copied it should apply the same constraints to their copy. |
| Apache XmlSchema doesn't limit how deeply schema imports and includes can be nested, so a malicious schema can make parsing recurse until the stack overflows. This causes a denial of service.
Users are recommended to upgrade to version 2.3.3, which fixes this issue. |
| Apache XmlSchema doesn't limit how deeply schema structures can be nested when it builds its schema model, so a malicious schema can make parsing recurse until the stack overflows. This causes a denial of service.
Users are recommended to upgrade to version 2.3.3, which fixes this issue. |
| The Apache XmlSchema walker (xmlschema-walker) doesn't detect cycles in type derivation, substitution groups, model groups or attribute groups. A malicious schema with such a cycle can make the walker recurse until the stack overflows, causing a denial of service.
Users are recommended to upgrade to version 2.3.3, which fixes this issue. |
| Authentication bypass via LDAP injection in component sshd-ldap in Apache MINA SSHD versions 1.2.0 to 2.19.0 and 3.0.0-M1 to 3.0.0-M5.
Apache MINA SSHD is a Java library for client-side and server-side SSH.
The optional sshd-ldap component provides support for integrating
password and publickey authentication on the server side with an LDAP
server.
sshd-ldap is an optional component. SSH servers implemented with Apache
MINA SSHD are affected only if they use sshd-ldap and do configure it to be used for password of public key authentication.
Other Apache MINA SSHD servers are not affected.
Lack of escaping LDAP filter metacharacters enabled successful authentication with username "*" and password "*".
Users are recommended to upgrade affected applications to version 2.20.0 or 3.0.0-M6, which fix this issue by properly escaping filter parameters according to RFC 4515. |
| Apache WSS4J accepted attacker-controlled derived-key lengths and offsets without adequate bounds. This could permit cryptographically weak keys or excessive CPU and memory consumption when processing crafted WS-Security messages. The fixes enforce a minimum key length of 16 bytes, a maximum length of 512 bytes, and a maximum offset of 4096 bytes.
Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4, which fix this issue. |
| The scriptPath parameter is incorporated into a /bin/sh -c command without sufficient neutralization of shell metacharacters, allowing shell command substitution and execution.
An authenticated user can exploit this behavior by creating a resource whose filename contains shell command substitution syntax, such as $(...), and subsequently supplying the resulting path to the Alert Script plugin's /test-send endpoint. When the alert script is executed, the shell interprets the injected command, resulting in arbitrary command execution with the privileges of the DolphinScheduler service process.
This issue affects Apache DolphinScheduler: before 3.4.3.
Users are recommended to upgrade to version 3.4.3, which fixes the issue. |
| Server-side memory exhaustion in Apache MINA SSHD 1.0.0 to 2.19.0 and 3.0.0-M1 to 3.0.0-M5, component sshd-sftp, in the SFTP v6 check-file-name/check-file-handle extension. Apache MINA SSHD is a Java library for client-side and server-side SSH.
Using a very small "block size" (for instance 256, which is the minimum) on a huge file generates many (file size / block size) hashes. The resulting SFTP reply message was accumulated fully in memory server-side, which could, with a suitably large (possibly sparse) file exhaust the server-side memory, taking down the server.
Users are recommended to upgrade to version 2.20.0 or 3.0.0-M6, which fix this issue by imposing a maximum limit on the size of the reply. Many SFTP implementations have a general limit on the size of SFTP messages anyway; typically 256kB as in OpenSSH or also in Apache MINA SSHD. |
| LDAPCache and LDAPBackingEngine build LDAP search filters for user lookup and role lookup by textually substituting the placeholders %u, %dn, and %fqdn (drawn from the login name, the resolved user DN, and its fully qualified namespace form) into administrator-configured filter templates (userFilter, roleFilter). Before the fix, the only sanitization applied to the substituted value was double backslashed:
filter = filter.replaceAll(Pattern.quote("%u"), Matcher.quoteReplacement(user));
filter = filter.replace("\\", "\\\\");
This does not escape the other characters RFC 4515 requires escaping in an LDAP search filter: *, (, ), and NUL. A login name containing any of these can change the structure of the resulting filter rather than being matched as a literal value (e.g. a crafted username can turn an equality match into a wildcard match, or close/reopen filter clauses), widening what the search returns and potentially causing a login or role lookup to match an LDAP entry other than the intended one, over-granting roles, and depending on deployment-specific filter templates, potentially affecting which account a login resolved to.
It's not exploitable through every entry points: LDAPLoginModule and LDAPPubkeyLoginModule both called Util.doRFC2254Encoding() (correct RFC 4515 escaping) on the login name before handing it to LDAPCache, which masked the missing escaping in LDAPCache for those two call paths. Using LDAPCache directly (bypassing the login modules) does not reproduce through the normal LDAPLoginModule/LDAPPubkeyLoginModule authentication flow for this reason. It does reproduce through two other call paths that reach LDAPCache/LDAPBackingEngine without any prior escaping:
* GSSAPILdapLoginModule passes the NameCallback name straight through, unescaped.
* LDAPBackingEngine (listRoles) passes principal.getName() straight through, unescaped. |
| An improper neutralization of input during web page generation ('Cross-site Scripting') [CWE-79] vulnerability when using the XSSAPI.getValidHref() in Apache Sling XSS version 2.4.10 and prior may allow an attacker to perform a reflected cross-site scripting (XSS) attack in every feature using this method. In order to successfully attack an application, the attacker needs to be able to submit a value which is not correctly sanitized by that library.
Upgrade to Apache Sling XSS >= 2.4.12 |
| Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in Apache Sling XSS.
This issue affects Apache Sling XSS: before 2.4.12.
Users are recommended to upgrade to version 2.4.12, which fixes the issue. |
| Apache MINA SSHD is a Java library for client-side and server-side SSH. SSH servers can be configured to require multi-authentication schemes, for instance two different public keys, not just one. In OpenSSH, this would be done by setting in sshd_config AuthenticationMethods "publickey,publickey". Apache MINA SSHD provides an equivalent configuration mechanism.
In Apache MINA SSHD versions up to 2.19.0 and 3.0.0-M1 to 3.0.0-M5 the server code in component sshd-core does not enforce that the two public keys presented are different. A user can thus successfully authenticate with only one of the two key pairs required by presenting this single key twice. This is a partial authentication bypass.
Users are recommended to upgrade to version 2.20.0 or 3.0.0-M6, which fix this issue. |
| Possible memory exhaustion in SFTP clients (DefaultSftpClient) in component sshd-sftp in Apache MINA SSHD versions 0.9.0 to 2.19.0 and 3.0.0-M1 to 3.0.0-M5.
Apache
MINA SSHD is a Java library for client-side and server-side SSH. The sshd-sftp component provides support for SFTP.
The SFTP client implementation, when receiving a reply, did not check that this reply corresponded to a request sent earlier. Unsolicited replies would be stored but never consumed. A malicious server could keep sending unsolicited replies until available memory in the client was exhausted.
Users are recommended to upgrade to version 2.20.0 or 3.0.0-M6, which fix this issue. |
| Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in Apache Sling XSS.
This issue affects Apache Sling XSS: before 2.4.12.
Users are recommended to upgrade to version 2.4.12, which fixes the issue. |
