#java

By Deeba Ahmed The 8220 gang, believed to be of Chinese origins, was first identified in 2017 by Cisco Talos when they targeted Drupal, Hadoop YARN, and Apache Struts2 applications for propagating cryptojacking malware. This is a post from HackRead.com Read the original post: 8220 Gang Targets Telecom and Healthcare in Global Cryptojacking Attack

Apache Airflow, versions 2.6.0 through 2.7.3 has a stored XSS vulnerability that allows a DAG author to add an unbounded and not-sanitized javascript in the parameter description field of the DAG. This Javascript can be executed on the client side of any of the user who looks at the tasks in the browser sandbox. While this issue does not allow to exit the browser sandbox or manipulation of the server-side data - more than the DAG author already has, it allows to modify what the user looking at the DAG details sees in the browser - which opens up all kinds of possibilities of misleading other users. Users of Apache Airflow are recommended to upgrade to version 2.8.0 or newer to mitigate the risk associated with this vulnerability

Improper Authentication vulnerability in Apache Pulsar WebSocket Proxy allows an attacker to connect to the /pingpong endpoint without authentication. This issue affects Apache Pulsar WebSocket Proxy: from 2.8.0 through 2.8.*, from 2.9.0 through 2.9.*, from 2.10.0 through 2.10.4, from 2.11.0 through 2.11.1, 3.0.0. The known risks include a denial of service due to the WebSocket Proxy accepting any connections, and excessive data transfer due to misuse of the WebSocket ping/pong feature. 2.10 Pulsar WebSocket Proxy users should upgrade to at least 2.10.5. 2.11 Pulsar WebSocket Proxy users should upgrade to at least 2.11.2. 3.0 Pulsar WebSocket Proxy users should upgrade to at least 3.0.1. 3.1 Pulsar WebSocket Proxy users are unaffected. Any users running the Pulsar WebSocket Proxy for 2.8, 2.9, and earlier should upgrade to one of the above patched versions.

### Impact It's possible to execute a Velocity script without script right through the document tree. To reproduce: * As a user without script right, create a document, e.g., named Nasty Title * Set the document's title to `$request.requestURI` * Click "Save & View" * Reload the page in the browser The navigation panel displays a document named with the current URL, showing that the Velocity code has been executed even though the user doesn't have script right. ### Patches This has been patched in XWiki 14.10.7 and 15.2RC1. ### Workarounds A possible workaround is to: * modify the page XWiki.DocumentTreeMacros * search for the code `#set ($discard = $translatedDocument.setTitle($translatedDocument.title))` * modify it into `#set ($discard = $translatedDocument.setcomment(''))` ### References * https://jira.xwiki.org/browse/XWIKI-20625 * https://github.com/xwiki/xwiki-platform/commit/41d7dca2d30084966ca6a7ee537f39ee8354a7e3 ### For more information If you have any questions ...

This improper authorization vulnerability allows an unauthenticated attacker to reset Confluence and create a Confluence instance administrator account. Using this account, an attacker can then perform all administrative actions that are available to the Confluence instance administrator. This Metasploit module uses the administrator account to install a malicious .jsp servlet plugin which the user can trigger to gain code execution on the target in the context of the of the user running the confluence server.

### Impact Prior to this fix, the GraphQL query parsing was vulnerable to `StackOverflowError`s. The possibility of small queries resulting in stack overflow is a potential denial of service vulnerability. This potentially affects all applications using Grackle which have untrusted users. > [!CAUTION] > **No specific knowledge of an application's GraphQL schema would be required to construct a pathological query.** ### Patches The stack overflow issues have been resolved in the v0.18.0 release of Grackle. ### Workarounds Users could interpose a sanitizing layer in between untrusted input and Grackle query processing.

### Impact A ReDoS (Regular expression Denial of Service) vulnerability has been identified in Sentry's Astro SDK 7.78.0-7.86.0. Under certain conditions, this vulnerability allows an attacker to cause excessive computation times on the server, leading to denial of service (DoS). Applications that are using Sentry's Astro SDK are affected if: 1. They're using Sentry instrumentation: - they have [manually registered](https://docs.sentry.io/platforms/javascript/guides/astro/manual-setup/#manually-add-server-instrumentation) Sentry Middleware (affected versions 7.78.0-7.86.0); - or [configured](https://docs.sentry.io/platforms/javascript/guides/astro/manual-setup/#configure-server-instrumentation) Astro in SSR (server) or hybrid mode, use Astro 3.5.0 and newer and didn’t [disable the automatic server instrumentation](https://docs.sentry.io/platforms/javascript/guides/astro/manual-setup/#disable-auto-server-instrumentation) (affected versions 7.82.0-7.86.0). 2. They have configured...

### Impact Resque Scheduler version 1.27.4 and above are affected by a cross-site scripting vulnerability. A remote attacker can inject javascript code to the "{schedule_job}" or "args" parameter in /resque/delayed/jobs/{schedule_job}?args={args_id} to execute javascript at client side. ### Patches Fixed in v4.10.2 ### Workarounds No known workarounds at this time. It is recommended to not click on 3rd party or untrusted links to the resque-web interface until you have patched your application. ### References * https://nvd.nist.gov/vuln/detail/CVE-2022-44303 * https://github.com/resque/resque-scheduler/issues/761 * https://github.com/resque/resque/issues/1885 * https://github.com/resque/resque-scheduler/pull/780 * https://github.com/resque/resque-scheduler/pull/783

### Summary Russh v0.40.1 and earlier is vulnerable to a novel prefix truncation attack (a.k.a. Terrapin attack), which allows a man-in-the-middle attacker to strip an arbitrary number of messages right after the initial key exchange, breaking SSH extension negotiation (RFC8308) in the process and thus downgrading connection security. ### Mitigations To mitigate this protocol vulnerability, OpenSSH suggested a so-called "strict kex" which alters the SSH handshake to ensure a Man-in-the-Middle attacker cannot introduce unauthenticated messages as well as convey sequence number manipulation across handshakes. Support for strict key exchange has been added to Russh in the patched version. **Warning: To take effect, both the client and server must support this countermeasure.** As a stop-gap measure, peers may also (temporarily) disable the affected algorithms and use unaffected alternatives like AES-GCM instead until patches are available. ### Details The SSH specifications of Ch...

### Impact Anyone who can edit an arbitrary wiki page in an XWiki installation can gain programming right through several cases of missing escaping in the code for displaying sections in the administration interface. This impacts the confidentiality, integrity and availability of the whole XWiki installation. Normally, all users are allowed to edit their own user profile so this should be exploitable by all users of the XWiki instance. The easiest way to reproduce this is to edit any document with the object editor and add an object of type `XWiki.ConfigurableClass` ("Custom configurable sections"). Set "Display in section" and "Display in Category" to "other", set scope to "Wiki and all spaces" and "Heading" to `{{async}}{{groovy}}services.logging.getLogger("attacker").error("Attack from Heading succeeded!"); println("Hello from Groovy!"){{/groovy}}{{/async}}`. Click "Save". Open `<xwiki-host>/xwiki/bin/view/Main/?sheet=XWiki.AdminSheet&viewer=content&editor=globaladmin&section=othe...