Security
Headlines
HeadlinesLatestCVEs

Tag

#web

CVE-2023-4772: Changeset 2955097 for newsletter – WordPress Plugin Repository

The Newsletter plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'newsletter_form' shortcode in versions up to, and including, 7.8.9 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers with contributor-level and above permissions to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

CVE
#xss#web#wordpress#php#auth
A history of ransomware: How did it get this far?

Categories: News Categories: Ransomware Tags: history Tags: ransomware Tags: bulletproof hosting Tags: cryptocurrency Tags: encryption Tags: fast internet Tags: government protection Tags: RaaS Tags: LockBit Tags: pentester tools Tags: code We tell you about the origin of ransomware and what factors contributed to making it the most feared type of malware. (Read more...) The post A history of ransomware: How did it get this far? appeared first on Malwarebytes Labs.

CVE-2023-41329: Domain restrictions bypass via DNS Rebinding in WireMock and WireMock Studio webhooks, proxy and recorder modes

WireMock is a tool for mocking HTTP services. The proxy mode of WireMock, can be protected by the network restrictions configuration, as documented in Preventing proxying to and recording from specific target addresses. These restrictions can be configured using the domain names, and in such a case the configuration is vulnerable to the DNS rebinding attacks. A similar patch was applied in WireMock 3.0.0-beta-15 for the WireMock Webhook Extensions. The root cause of the attack is a defect in the logic which allows for a race condition triggered by a DNS server whose address expires in between the initial validation and the outbound network request that might go to a domain that was supposed to be prohibited. Control over a DNS service is required to exploit this attack, so it has high execution complexity and limited impact. This issue has been addressed in version 2.35.1 of wiremock-jre8 and wiremock-jre8-standalone, version 3.0.3 of wiremock and wiremock-standalone, version 2.6.1 of ...

CVE-2023-23623: Content-Secrity-Policy disabling eval not applied consistently in renderers with sandbox disabled

Electron is a framework which lets you write cross-platform desktop applications using JavaScript, HTML and CSS. A Content-Security-Policy that disables eval, specifically setting a `script-src` directive and _not_ providing `unsafe-eval` in that directive, is not respected in renderers that have sandbox disabled. i.e. `sandbox: false` in the `webPreferences` object. This allows usage of methods like `eval()` and `new Function` unexpectedly which can result in an expanded attack surface. This issue only ever affected the 22 and 23 major versions of Electron and has been fixed in the latest versions of those release lines. Specifically, these versions contain the fixes: 22.0.1 and 23.0.0-alpha.2 We recommend all apps upgrade to the latest stable version of Electron. If upgrading isn't possible, this issue can be addressed without upgrading by enabling `sandbox: true` on all renderers.

CVE-2023-41327: Release 3.0.0-beta-15 · wiremock/wiremock

WireMock is a tool for mocking HTTP services. WireMock can be configured to only permit proxying (and therefore recording) to certain addresses. This is achieved via a list of allowed address rules and a list of denied address rules, where the allowed list is evaluated first. Until WireMock Webhooks Extension 3.0.0-beta-15, the filtering of target addresses from the proxy mode DID NOT work for Webhooks, so the users were potentially vulnerable regardless of the `limitProxyTargets` settings. Via the WireMock webhooks configuration, POST requests from a webhook might be forwarded to an arbitrary service reachable from WireMock’s instance. For example, If someone is running the WireMock docker Container inside a private cluster, they can trigger internal POST requests against unsecured APIs or even against secure ones by passing a token, discovered using another exploit, via authentication headers. This issue has been addressed in versions 2.35.1 and 3.0.3 of wiremock. Wiremock studio h...

CVE-2023-39967: Controlled and full-read SSRF through URL parameter when testing a request, webhooks and proxy mode in WireMock Studio

WireMock is a tool for mocking HTTP services. When certain request URLs like “@127.0.0.1:1234" are used in WireMock Studio configuration fields, the request might be forwarded to an arbitrary service reachable from WireMock’s instance. There are 3 identified potential attack vectors: via “TestRequester” functionality, webhooks and the proxy mode. As we can control HTTP Method, HTTP Headers, HTTP Data, it allows sending requests with the default level of credentials for the WireMock instance. The vendor has discontinued the affected Wiremock studio product and there will be no fix. Users are advised to find alternatives.

GHSA-hq8w-9w8w-pmx7: WireMock Controlled Server Side Request Forgery vulnerability through URL

### Impact WireMock can be configured to only permit proxying (and therefore recording) to certain addresses. This is achieved via a list of allowed address rules and a list of denied address rules, where the allowed list is evaluated first. [Documentation](https://wiremock.org/docs/configuration/#preventing-proxying-to-and-recording-from-specific-target-addresses). Until WireMock Webhooks Extension [3.0.0-beta-15](https://github.com/wiremock/wiremock/releases/tag/3.0.0-beta-15), the filtering of target addresses from the proxy mode DID NOT work for Webhooks, so the users were potentially vulnerable regardless of the `limitProxyTargets` settings. Via the WireMock webhooks configuration, POST requests from a webhook might be forwarded to an arbitrary service reachable from WireMock’s instance. For example, If someone is running the WireMock docker Container inside a private cluster, they can trigger internal POST requests against unsecured APIs or even against secure ones by passin...

CVE-2023-41601

Multiple cross-site scripting (XSS) vulnerabilities in install/index.php of CSZ CMS v1.3.0 allow attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Database Username or Database Host parameters.

CVE-2023-40591: Vulnerability disclosure | go-ethereum

go-ethereum (geth) is a golang execution layer implementation of the Ethereum protocol. A vulnerable node, can be made to consume unbounded amounts of memory when handling specially crafted p2p messages sent from an attacker node. The fix is included in geth version `1.12.1-stable`, i.e, `1.12.2-unstable` and onwards. Users are advised to upgrade. There are no known workarounds for this vulnerability.

GHSA-gxh7-wv9q-fwfr: Electron's Content-Secrity-Policy disabling eval not applied consistently in renderers with sandbox disabled

### Impact A Content-Security-Policy that disables eval, specifically setting a `script-src` directive and _not_ providing `unsafe-eval` in that directive, is not respected in renderers that have sandbox and contextIsolation disabled. i.e. `sandbox: false` and `contextIsolation: false` in the `webPreferences` object. This resulted in incorrectly allowing usage of methods like `eval()` and `new Function`, which can result in an expanded attack surface. ### Patches This issue only ever affected the 22 and 23 major versions of Electron and has been fixed in the latest versions of those release lines. Specifically, these versions contain the fixes: - 22.0.1 - 23.0.0-alpha.2 We recommend all apps upgrade to the latest stable version of Electron, especially if they use `sandbox: false` or `contextIsolation: false`. ### Workarounds If upgrading isn't possible, this issue can be addressed without upgrading by enabling at least one of `sandbox: true` or `contextIsolation: true` on all ren...