#php

### TL;DR This vulnerability affects all Kirby setups that use PHP's built-in server. Such setups are commonly only used during local development. Sites that use other server software (such as Apache, nginx or Caddy) are *not* affected. ---- ### Introduction For use with PHP's built-in web server, Kirby provides a `router.php` file. The router delegates requests to static files to PHP so that assets and other static files in the document root can be accessed by the browser. This logic was vulnerable against path traversal attacks. By using special elements such as `..` and `/` separators, attackers can escape outside of the restricted location to access files or directories that are elsewhere on the system. One of the most common special elements is the `../` sequence, which in most modern operating systems is interpreted as the parent directory of the current location. ### Impact The missing path traversal check allowed attackers to navigate all files on the server that were a...

### TL;DR This vulnerability affects all Kirby sites that use the `collection()` helper or `$kirby->collection()` method with a dynamic collection name (such as a collection name that depends on request or user data). Sites that only use fixed calls to the `collection()` helper/`$kirby->collection()` method (i.e. calls with a simple string for the collection name) are *not* affected. ---- ### Introduction Kirby's `collection()` helper and `$kirby->collection()` method (in the following abbreviated to the `collection()` helper) allow to load PHP logic files that are normally stored in the `site/collections` folder or registered by plugins through the `collections` plugin extension. If the `collection()` helper is called with an arbitrary collection name, Kirby first checks if a file with this name exists in the collections root (which defaults to `site/collections`). This logic was vulnerable against path traversal attacks. By using special elements such as `..` and `/` separator...

An issue was discovered in post.php in bootstrap-multiselect (aka Bootstrap Multiselect) 1.1.2. A PHP script in the source code echoes arbitrary POST data. If a developer adopts this structure wholesale in a live application, it could create a Reflective Cross-Site Scripting (XSS) vulnerability exploitable through Cross-Site Request Forgery (CSRF).

Craft CMS stores arbitrary content provided by unauthenticated users in session files. This content could be accessed and executed, possibly using an independent vulnerability. Craft CMS redirects requests that require authentication to the login page and generates a session file on the server at `/var/lib/php/sessions`. Such session files are named `sess_[session_value]`, where `[session_value]` is provided to the client in a `Set-Cookie` response header. Craft CMS stores the return URL requested by the client without sanitizing parameters. Consequently, an unauthenticated client can introduce arbitrary values, such as PHP code, to a known local file location on the server. Craft CMS versions 5.7.5 and 4.15.3 have been released to address this issue.

### Summary Cross-site scripting (XSS) vulnerability in the [Attributes extension](https://commonmark.thephpleague.com/extensions/attributes/) of the league/commonmark library (versions 1.5.0 through 2.6.x) allows remote attackers to insert malicious JavaScript calls into HTML. ### Details The league/commonmark library provides configuration options such as `html_input: 'strip'` and `allow_unsafe_links: false` to mitigate cross-site scripting (XSS) attacks by stripping raw HTML and disallowing unsafe links. However, when the Attributes Extension is enabled, it introduces a way for users to inject arbitrary HTML attributes into elements via Markdown syntax using curly braces. As a result, even with the secure configuration shown above, an attacker can inject dangerous attributes into applications using this extension via a payload such as: ```md ![](){onerror=alert(1)} ``` Which results in the following HTML: ```html <p><img onerror="alert(1)" src="" alt="" /></p> ``` Which cause...

Cybersecurity researchers have shed light on a new campaign targeting WordPress sites that disguises the malware as a security plugin. The plugin, which goes by the name "WP-antymalwary-bot.php," comes with a variety of features to maintain access, hide itself from the admin dashboard, and execute remote code. "Pinging functionality that can report back to a command-and-control (C&C) server

WordPress sites are under threat from a deceptive anti-malware plugin. Learn how this malware grants backdoor access, hides…

An unrestricted file upload vulnerability in ShowDoc caused by improper validation of file extension allows execution of arbitrary PHP, leading to remote code execution. This issue affects ShowDoc: before 2.8.7.

### Summary A stored cross-site scripting (XSS) vulnerability was discovered in the application’s comments feature. This issue allows a malicious actor to inject JavaScript payloads that are stored and later executed in the browser of any user viewing the affected comment. The XSS occurs because the application fails to properly sanitize or encode user input submitted to the comments. Notably, the application sanitizes or does not allow execution of `<script>` tags, but does not account for payloads obfuscated using JavaScript block comments like `/* JavaScriptPayload */`. ### PoC Navigate to a site and page that allows comments and place this in the comments section and submit it: `/*<script>alert('pizzapower')</script>*/` Upon submitting to the page, it will run. And then upon every page visit, it will run. ### Impact An attacker can run arbitrary JS in the victim's browser (any user that visits the page with the comments). This can be chained to do many malicious actions, ...

### Summary An arbitrary file write can be used to write a file with a PHP extension, which then can be browsed to in order to execute arbitrary code on the server. All testing was performed on a local docker setup running the latest version of the application. ### PoC Proof of Concept Navigate to `http://localhost:8085/?LookWiki` which allows you to click `Create a new Graphical configuration` where you specify some parameters and then click `Save`.  After clicking save, this request is made (most headers removed for clarity): ``` POST /?api/templates/custom-presets/test.css HTTP/1.1 Host: localhost:8085 primary-color=%230c5d6a&secondary-color-1=%23d8604c&secondary-color-2=%23d78958&neutral-color=%234e5056&neutral-soft-color=%2357575c&neutral-light-color=%23f2f2f2&main-text-fontsize=17px&main-text-fontfamily=%22Nunito%22%2C+sans-serif&main-title-fontfamily='Nunito'%2C+sans-serif ``` ...