#ldap

Bouncy Castle provides the X509LDAPCertStoreSpi.java class which can be used in conjunction with the CertPath API for validating certificate paths. Pre-1.73 the implementation did not check the X.500 name of any certificate, subject, or issuer being passed in for LDAP wild cards, meaning the presence of a wild car may lead to Information Disclosure. A potential attack would be to generate a self-signed certificate with a subject name that contains special characters, e.g: CN=Subject*)(objectclass=. This will be included into the filter and provides the attacker ability to specify additional attributes in the search query. This can be exploited as a blind LDAP injection: an attacker can enumerate valid attribute values using the boolean blind injection technique. The exploitation depends on the structure of the target LDAP directory, as well as what kind of errors are exposed to the user. Changes to the X509LDAPCertStoreSpi.java class add the additional checking of any X.500 name used...

Bouncy Castle For Java before 1.74 is affected by an LDAP injection vulnerability. The vulnerability only affects applications that use an LDAP CertStore from Bouncy Castle to validate X.509 certificates. During the certificate validation process, Bouncy Castle inserts the certificate's Subject Name into an LDAP search filter without any escaping, which leads to an LDAP injection vulnerability.

Ubuntu Security Notice 6197-1 - It was discovered that OpenLDAP was not properly performing bounds checks when executing functions related to LDAP URLs. An attacker could possibly use this issue to cause a denial of service.

An issue was discovered in SubmitEntityAction in Wikibase in MediaWiki through 1.39.3. Because it doesn't use EditEntity for undo and restore, the intended interaction with AbuseFilter does not occur.

An issue was discovered in the ProofreadPage (aka Proofread Page) extension for MediaWiki through 1.39.3. In includes/Page/PageContentHandler.php and includes/Page/PageDisplayHandler.php, hidden users can be exposed via public interfaces.

Red Hat Security Advisory 2023-3954-01 - This release of Red Hat Fuse 7.12 serves as a replacement for Red Hat Fuse 7.11 and includes bug fixes and enhancements, which are documented in the Release Notes document linked in the References. Issues addressed include bypass, code execution, denial of service, information leakage, resource exhaustion, server-side request forgery, and traversal vulnerabilities.

A minor version update (from 7.11 to 7.12) is now available for Red Hat Fuse. The purpose of this text-only errata is to inform you about the security issues fixed in this release. Red Hat Product Security has rated this update as having a security impact of Critical. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original. Related CVEs: * CVE-2012-5783: It was found that Apache Commons HttpClient 3.x, as used in Amazon Flexible Payments Service (FPS) merchant Java SDK and other products, does not verify that the server hostname matches a domain name in the subject's Common Name (CN) or su...

The Active Directory Integration / LDAP Integration plugin for WordPress is vulnerable to LDAP Injection in versions up to, and including, 4.1.5. This is due to insufficient escaping on the supplied username value. This makes it possible for unauthenticated attackers to extract potentially sensitive information from the LDAP directory.

IBM Informix JDBC Driver 4.10 and 4.50 is susceptible to remote code execution attack via JNDI injection when driver code or the application using the driver do not verify supplied LDAP URL in Connect String. IBM X-Force ID: 249511.

Apereo CAS is an open source multilingual single sign-on solution for the web. Apereo CAS can be configured to use authentication based on client X509 certificates. These certificates can be provided via TLS handshake or a special HTTP header, such as “ssl_client_cert”. When checking the validity of the provided client certificate, X509CredentialsAuthenticationHandler performs check that this certificate is not revoked. To do so, it fetches URLs provided in the “CRL Distribution Points” extension of the certificate, which are taken from the certificate itself and therefore can be controlled by a malicious user. If the CAS server is configured to use an LDAP server for x509 authentication with a password, for example by setting a “cas.authn.x509.ldap.ldap-url” and “cas.authn.x509.ldap.bind-credential” properties, X509CredentialsAuthenticationHandler fetches revocation URLs from the certificate, which can be LDAP urls. When making requests to this LDAP urls, Apereo CAS uses the same pass...