#java

### Summary An improper URI validation vulnerability exists that enables an unauthorized attacker to perform XML External Entities (XEE) attack, then send GET request to any HTTP server. Attacker can abuse this to scan internal networks and gain information about them then exploit further. Moreover, attacker can read limited `.xsd` file on system. ### Details By default, GeoServer use `PreventLocalEntityResolver` class from GeoTools to filter out malicious URIs in XML entities before resolving them. The URI must match the regex `(?i)(jar:file|http|vfs)[^?#;]*\\.xsd`. But the regex leaves a chance for attackers to request to any HTTP server or limited file. ### Impact An unauthenticated attacker can: 1. Scan internal network to gain insight about it and exploit further. 2. SSRF to endpoint ends with `.xsd`. 3. Read limited `.xsd` file on system. ### Mitigation 1. Define the system property ``ENTITY_RESOLUTION_ALLOWLIST`` to limit the supported external schema locaitons. 2. The buil...

### Summary It possible to achieve Service Side Request Forgery (SSRF) via the Demo request endpoint if Proxy Base URL has not been set. ### Details A unauthenticated user can supply a request that will be issued by the server. This can be used to enumerate internal networks and also in the case of cloud instances can be used to obtain sensitive data. ### Mitigation 1. When using GeoServer with a proxy, manage the proxy base value as a system administrator, use the application property ``PROXY_BASE_URL`` to provide a non-empty value that cannot be overridden by the user interface or incoming request. 2. When using GeoServer directly without a proxy, block all access to TestWfsPost by editing the web.xml file. Adding this block right before the end: ```xml <security-constraint> <web-resource-collection> <web-resource-name>BlockDemoRequests</web-resource-name> <url-pattern>/TestWfsPost/*</url-pattern> </web-resource-coll...

Google has fixed a vulnerability in its account recovery flow which could have allowed attackers to find linked phone numbers.

A possible security vulnerability has been identified in Apache Kafka. This requires access to a alterConfig to the cluster resource, or Kafka Connect worker, and the ability to create/modify connectors on it with an arbitrary Kafka client SASL JAAS config and a SASL-based security protocol, which has been possible on Kafka clusters since Apache Kafka 2.0.0 (Kafka Connect 2.3.0). When configuring the broker via config file or AlterConfig command, or connector via the Kafka Kafka Connect REST API, an authenticated operator can set the `sasl.jaas.config` property for any of the connector's Kafka clients to "com.sun.security.auth.module.LdapLoginModule", which can be done via the `producer.override.sasl.jaas.config`, `consumer.override.sasl.jaas.config`, or `admin.override.sasl.jaas.config` properties. This will allow the server to connect to the attacker's LDAP server and deserialize the LDAP response, which the attacker can use to execute java deserialization gadget chains on the Kafka ...

In CVE-2023-25194, we announced the RCE/Denial of service attack via SASL JAAS JndiLoginModule configuration in Kafka Connect API. But not only Kafka Connect API is vulnerable to this attack, the Apache Kafka brokers also have this vulnerability. To exploit this vulnerability, the attacker needs to be able to connect to the Kafka cluster and have the AlterConfigs permission on the cluster resource. Since Apache Kafka 3.4.0, we have added a system property ("-Dorg.apache.kafka.disallowed.login.modules") to disable the problematic login modules usage in SASL JAAS configuration. Also by default "com.sun.security.auth.module.JndiLoginModule" is disabled in Apache Kafka 3.4.0, and "com.sun.security.auth.module.JndiLoginModule,com.sun.security.auth.module.LdapLoginModule" is disabled by default in in Apache Kafka 3.9.1/4.0.0

A possible arbitrary file read and SSRF vulnerability has been identified in Apache Kafka Client. Apache Kafka Clients accept configuration data for setting the SASL/OAUTHBEARER connection with the brokers, including "sasl.oauthbearer.token.endpoint.url" and "sasl.oauthbearer.jwks.endpoint.url". Apache Kafka allows clients to read an arbitrary file and return the content in the error log, or sending requests to an unintended location. In applications where Apache Kafka Clients configurations can be specified by an untrusted party, attackers may use the "sasl.oauthbearer.token.endpoint.url" and "sasl.oauthbearer.jwks.endpoint.url" configuratin to read arbitrary contents of the disk and environment variables or make requests to an unintended location. In particular, this flaw may be used in Apache Kafka Connect to escalate from REST API access to filesystem/environment/URL access, which may be undesirable in certain environments, including SaaS products. Since Apache Kafka 3.9.1/4.0.0,...

**According to the CVSS metric, successful exploitation of this vulnerability could lead to some loss of confidentiality (C:L)? What does that mean for this vulnerability?** Information in the victim's browser associated with the vulnerable URL can be read by the malicious JavaScript code and sent to the attacker.

### Summary GeoTools Schema class use of Eclipse XSD library to represent schema data structure is vulnerable to XML External Entity (XXE) exploit. ### Impact This impacts whoever exposes XML processing with ``gt-xsd-core`` involved in parsing, when the documents carry a reference to an external XML schema. The ``gt-xsd-core`` Schemas class is not using the EntityResolver provided by the ParserHandler (if any was configured). This also impacts users of ``gt-wfs-ng`` DataStore where the ENTITY_RESOLVER connection parameter was not being used as intended. ### Resolution GeoTools API change allows EntityResolver to be supplied to the following methods: ```java Schemas.parse( location, locators, resolvers, uriHandlers, entityResolver); Schemas.findSchemas(Configuration configuration, EntityResolver entityResolver); ``` With this API change the `gt-wfs-ng` WFS DataStore ENTITY_RESOLVER parameter is now used. ### Reference * [GHSA-jj54-8f66-c5pc](https://github.com/geoserver/geoser...

### Summary The application does not sufficiently sanitize user input, allowing for the execution of arbitrary JavaScript code. The 'saveNode' and 'saveManifest' endpoints take user input and store it in the JSON schema for the site. This content is then rendered in the generated HAX site. Although the application does not allow users to supply a 'script' tag, it does allow the use of other HTML tags to run JavaScript. ### Affected Resources - [Operations.php:258](https://github.com/haxtheweb/haxcms-php/blob/master/system/backend/php/lib/Operations.php#L258) `saveManifest()` - [Operations.php:868](https://github.com/haxtheweb/haxcms-php/blob/master/system/backend/php/lib/Operations.php#L868) `saveNode()` - `https://<site>/<user>/system/api/saveNode` - `https://<site>/<user>/system/api/saveManifest` ### Impact An authenticated attacker can use the site editor and settings editor to store malicious payloads in a HAX site which execute arbitrary JavaScript when a user visits the sit...

### Impact The application is vulnerable to Cross-Site Scripting (XSS) attacks due to incorrect input validation and sanitization of user-input data. An attacker can inject arbitrary HTML code, including JavaScript scripts, into the page processed by the user's browser, allowing them to steal sensitive data, hijack user sessions, or conduct other malicious activities. ### Patches The issue is fixed in https://github.com/barryvdh/laravel-translation-manager/pull/475 which is released in version 0.6.8 ### Workarounds Only authenticated users with access to the translation manager are impacted. ### References [[PT-2025-04] laravel translation manager.pdf](https://github.com/user-attachments/files/20639250/PT-2025-04.laravel.translation.manager.pdf) ### Reported by Positive Technologies (Artem Deikov, Ilya Tsaturov, Daniil Satyaev, Roman Cheremnykh, Artem Danilov, Stanislav Gleym)