#vulnerability

Reflected cross-site scripting (XSS) vulnerability on the page configuration page in Liferay Portal 7.4.3.102 through 7.4.3.110, and Liferay DXP 2023.Q4.0 through 2023.Q4.2, and 2023.Q3.5 allows remote attackers to inject arbitrary web script or HTML via the com_liferay_layout_admin_web_portlet_GroupPagesPortlet_backURLTitle parameter.

Multiple cross-site scripting (XSS) vulnerabilities in the Calendar widget when inviting users to a event in Liferay Portal 7.4.3.35 through 7.4.3.110, and Liferay DXP 2023.Q4.0 through 2023.Q4.4, 2023.Q3.1 through 2023.Q3.6, 7.4 update 35 through update 92, and 7.3 update 25 through update 35 allow remote attackers to inject arbitrary web script or HTML via a crafted payload injected into a user’s (1) First Name, (2) Middle text, or (3) Last Name text fields.

Cross-site scripting (XSS) vulnerability in web content template in Liferay Portal 7.4.3.4 through 7.4.3.111, and Liferay DXP 2023.Q4.0 through 2023.Q4.4, 2023.Q3.1 through 2023.Q3.8, and 7.4 GA through update 92 allows remote authenticated users to inject arbitrary web script or HTML via a crafted payload injected into a web content structure's Name text field

### Summary AgentAPI prior to version [0.4.0](https://github.com/coder/agentapi/releases/tag/v0.4.0) was susceptible to a client-side DNS rebinding attack when hosted over plain HTTP on localhost. ### Impact An attacker could have gained access to the `/messages` endpoint served by the Agent API. This allowed for the unauthorized exfiltration of sensitive user data, specifically local message history, which could've included secret keys, file system contents, and intellectual property the user was working on locally. ### Remediation We've [implemented](https://github.com/coder/agentapi/pull/49) an `Origin` and `Host` header validating middleware and set a secure by default configuration. Please upgrade to version [0.4.0](https://github.com/coder/agentapi/releases/tag/v0.4.0) or later. ### Credits We'd like to thank [Evan Harris](https://github.com/eharris128) from [mcpsec.dev](https://mcpsec.dev/) for reporting this issue and following the coordinated disclosure [policy](https://co...

### Description A vulnerability exists in go-f3's justification verification caching mechanism where verification results are cached without properly considering the context of the message. An attacker can bypass justification verification by: 1. First submitting a valid message with a correct justification 2. Then reusing the same cached justification in contexts where it would normally be invalid This occurs because the cached verification does not properly validate the relationship between the justification and the specific message context it's being used with. ### Impact - Potential consensus integrity issues through invalid justification acceptance - Could affect network liveness if exploited systematically - May allow malicious actors to influence consensus decisions with invalid justifications - Requires significant power (350+ TiB due to power table rounding) to meaningfully exploit - It would also be difficult to exploit in a synchronised fashion, such that >1/3 of the netwo...

#### Description In minio-java versions prior to 8.6.0, XML tag values containing references to system properties or environment variables were automatically substituted with their actual values during processing. This unintended behavior could lead to the exposure of sensitive information, including credentials, file paths, or system configuration details, if such references were present in XML content from untrusted sources. #### Affected Versions - minio-java < 8.6.0 All applications utilizing affected versions of minio-java for parsing XML with potentially untrusted input are vulnerable. #### Impact This vulnerability poses a high risk of information disclosure. Attackers could craft malicious XML inputs to extract sensitive data from the system's properties or environment variables, potentially compromising security in applications relying on minio-java for object storage operations. #### Patches The issue is resolved in minio-java version 8.6.0 and later. In these versions, a...

### Summary There are three potential attacks of arbitrary code injection vulnerability in the composite action at _action.yml_. ### Details The GitHub Action variables `inputs.prek-version`, `inputs.extra_args`, and `inputs.extra-args` can be used to execute arbitrary code in the context of the action. ### PoC ```yaml - uses: j178/prek-action@v1.0.5 with: prek-version: $(printenv >> $GITHUB_STEP_SUMMARY && echo "0.2.2") extra_args: '&& echo "MY_SECRET with a character is: ${MY_SECRET:0:1}a${MY_SECRET:1}" >> $GITHUB_STEP_SUMMARY && echo ""' env: MY_SECRET: ${{ secrets.MY_SECRET }} ``` The previous example will print all the environment variables, and it will expose `MY_SECRET` environment variable value to the summary of the workflow. An attacker could potentially use this vector to compromise the security of the target repository, even passing unnotice because the action will run normally. ### Impact Critical, CWE-94

### Impact CWE-20: Improper Input Validation Low impact ### Patches Patched in v7.1.8 (commit https://github.com/mondeja/mkdocs-include-markdown-plugin/commit/7466d67aa0de8ffbc427204ad2475fed07678915) ### Workarounds No

### Impact Due to incorrect handling of the `mail.Address` values when a sender- or recipient address is passed to the corresponding `MAIL FROM` or `RCPT TO` commands of the SMTP client, this could lead to a possible wrong address routing or even to ESMTP parameter smuggling. #### Vulnerability details Instead of making use of the `String()` method of `mail.Address`, which takes care of proper escaping and quotation of mail address, we used the `Address` value of the `mail.Address` which is the raw value when passing it to our SMTP client. This meant, if a mail address like this was set: `"toni.tester@example.com> ORCPT=admin@admin.com"@example.com` for a sender or recipient, instead of the correctly quoted/escaped address, the SMTP client would get the raw value passed which would translate into something like this being passed to the SMTP server: `RCPT TO:<toni.tester@example.com> ORCPT=admin@admin.com@example.com>`. Since ORCTP is a valid command for the SMTP server, the mail wo...

SafeDep `vet` is vulnerable to a DNS rebinding attack due to lack of HTTP `Host` and `Origin` header validation. To exploit this vulnerability following conditions must be met: 1. A `vet` scan is executed and reports are saved as `sqlite3` database 2. A `vet` MCP server is running on default port with SSE transport that has access to the report database 3. The attacker lures the victim to attacker controlled website 4. Attacker leverages DNS rebinding to access `vet` SSE server on `127.0.0.1` through the website 5. Attacker uses MCP tools to read information from report database ### Impact Data from `vet` scan sqlite3 database may be exposed to remote attackers when `vet` is used as an MCP server in SSE mode with default ports through the sqlite3 query MCP tool. ### Patches * `v1.12.5` is released that patches the issue with `Host` and `Origin` header allow list and validation ### Workarounds * Use `stdio` (default) transport for SSE server