#java

An issue was discovered in Bouncy Castle Java Cryptography APIs before BC 1.78. When endpoint identification is enabled in the BCJSSE and an SSL socket is created without an explicit hostname (as happens with HttpsURLConnection), hostname verification could be performed against a DNS-resolved IP address in some situations, opening up a possibility of DNS poisoning.

### Summary Input in parameter notification_urls is not processed resulting in javascript execution in the application ### Details changedetection.io version: v0.45.21 https://github.com/dgtlmoon/changedetection.io/blob/0.45.21/changedetectionio/forms.py#L226 ``` for server_url in field.data: if not apobj.add(server_url): message = field.gettext('\'%s\' is not a valid AppRise URL.' % (server_url)) raise ValidationError(message) ``` ### PoC Setting > ADD Notification URL List  ``` "><img src=x onerror=alert(document.domain)> ```  Requests  ### Impact A reflected XSS vulnerability happens when the user ...

A vulnerability was found in Wildfly’s management interface. Due to the lack of limitation of sockets for the management interface, it may be possible to cause a denial of service hitting the nofile limit as there is no possibility to configure or set a maximum number of connections.

Jenkins Script Security Plugin provides a sandbox feature that allows low privileged users to define scripts, including Pipelines, that are generally safe to execute. Calls to code defined inside a sandboxed script are intercepted, and various allowlists are checked to determine whether the call is to be allowed. Multiple sandbox bypass vulnerabilities exist in Script Security Plugin 1335.vf07d9ce377a_e and earlier: - Crafted constructor bodies that invoke other constructors can be used to construct any subclassable type via implicit casts. - Sandbox-defined Groovy classes that shadow specific non-sandbox-defined classes can be used to construct any subclassable type. These vulnerabilities allow attackers with permission to define and run sandboxed scripts, including Pipelines, to bypass the sandbox protection and execute arbitrary code in the context of the Jenkins controller JVM.

Jenkins Subversion Partial Release Manager Plugin 1.0.1 and earlier programmatically sets the Java system property `hudson.model.ParametersAction.keepUndefinedParameters` whenever a build is triggered from a release tag with the 'Svn-Partial Release Manager' SCM. Doing so disables the fix for [SECURITY-170](https://www.jenkins.io/security/advisory/2016-05-11/#arbitrary-build-parameters-are-passed-to-build-scripts-as-environment-variables) / CVE-2016-3721. As of publication of this advisory, there is no fix.

Jenkins Telegram Bot Plugin 1.4.0 and earlier stores the Telegram Bot token unencrypted in its global configuration file `jenkinsci.plugins.telegrambot.TelegramBotGlobalConfiguration.xml` on the Jenkins controller as part of its configuration. This token can be viewed by users with access to the Jenkins controller file system. As of publication of this advisory, there is no fix.

Red Hat Security Advisory 2024-2651-03 - An update for the nodejs:16 module is now available for Red Hat Enterprise Linux 8.8 Extended Update Support. Issues addressed include a denial of service vulnerability.

In Apache ActiveMQ 6.x, the default configuration doesn't secure the API web context (where the Jolokia JMX REST API and the Message REST API are located). It means that anyone can use these layers without any required authentication. Potentially, anyone can interact with the broker (using Jolokia JMX REST API) and/or produce/consume messages or purge/delete destinations (using the Message REST API). To mitigate, users can update the default conf/jetty.xml configuration file to add authentication requirement: <bean id="securityConstraintMapping" class="org.eclipse.jetty.security.ConstraintMapping">   <property name="constraint" ref="securityConstraint" />   <property name="pathSpec" value="/" /> </bean> Or we encourage users to upgrade to Apache ActiveMQ 6.1.2 where the default configuration has been updated with authentication by default.

### Impact When performing XSLT transformations XMLUnit for Java did not disable XSLT extension functions by default. Depending on the XSLT processor being used this could allow arbitrary code to be executed when XMLUnit is used to transform data with a stylesheet who's source can not be trusted. If the stylesheet can be provided externally this may even lead to a remote code execution. ## Patches Users are advised to upgrade to XMLUnit for Java 2.10.0 where the default has been changed by means of https://github.com/xmlunit/xmlunit/commit/b81d48b71dfd2868bdfc30a3e17ff973f32bc15b ### Workarounds XMLUnit's main use-case is performing tests on code that generates or processes XML. Most users will not use it to perform arbitrary XSLT transformations. Users running XSLT transformations with untrusted stylesheets should explicitly use XMLUnit's APIs to pass in a pre-configured TraX `TransformerFactory` with extension functions disabled via features and attributes. The required `setFactor...

### Summary If directory listings are enabled for a directory that an untrusted user has upload privileges for, a malicious file name like `<img src=x onerror=alert(1)>.txt` will allow JavaScript code execution in the context of the web server’s domain. ### Details SWS generally does not perform escaping of HTML entities on any values inserted in the directory listing. At the very least `file_name` and `current_path` could contain malicious data however. `file_uri` could also be malicious but the relevant scenarios seem to be all caught by hyper. ### Impact For any web server that allow users to upload files or create directories under a name of their choosing this becomes a stored XSS vulnerability.