#vulnerability

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Monday placed three security flaws to its Known Exploited Vulnerabilities (KEV) catalog, citing evidence of active exploitation. The vulnerabilities added are as follows - CVE-2023-48788 (CVSS score: 9.3) - Fortinet FortiClient EMS SQL Injection Vulnerability CVE-2021-44529 (CVSS score: 9.8) - Ivanti

### Summary The `email` field in phpMyFAQ's user control panel page is vulnerable to stored XSS attacks due to the inadequacy of PHP's `FILTER_VALIDATE_EMAIL` function, which only validates the email format, not its content. This vulnerability enables an attacker to execute arbitrary client-side JavaScript within the context of another user's phpMyFAQ session. ### Details Despite using PHP's `FILTER_VALIDATE_EMAIL` function, the email field does not adequately validate the content of the email address. This means that malicious input, such as JavaScript code, can be accepted and stored in the database without being detected. When the stored data is retrieved and displayed on web pages, it is not properly sanitized to remove or neutralize any potentially harmful content, such as JavaScript code which leads to Stored XSS. ### PoC 1. Login as any user, go to the user control panel, change email to any valid email and intercept the request. 2. Modify the request’s email parameter to t...

### Summary The category image upload function in phpmyfaq is vulnerable to manipulation of the `Content-type` and `lang` parameters, allowing attackers to upload malicious files with a .php extension, potentially leading to remote code execution (RCE) on the system. ### Details In the file upload function of the category image, the `Content-type` can be manipulated to return an empty string for the extension and the `lang` parameter can be set to `.php.` to allow an attacker to save a file as `.PHP`. This allows the uploading of web shells which could lead to RCE on phpmyfaq. ### PoC 1. Generate a fake .GIF file that contains a php command using the tool `gifsicle` a. Cmd: `gifsicle < test1.gif --comment "<?php system('whoami'); ?>" > output.php.gif`  b. The contents of the file should look like this: ![image](https://github.com/thorsten/phpMyFAQ/assets/63487456/...

### Summary A SQL injection vulnerability has been discovered in the `insertentry` & `saveentry` when modifying records due to improper escaping of the email address. This allows any authenticated user with the rights to add/edit FAQ news to exploit this vulnerability to exfiltrate data, take over accounts and in some cases, even achieve RCE. ### PoC 1 - SQL Injection at insertentry: 1. Browse to “/admin/?action=editentry”, edit record and save. Intercept the POST request to "/admin/?action=insertentry" and modify the email and notes parameters in the body to the payloads below: a. `email=test'/*@email.com` b. `notes=*/,1,1,1,1,null,1);select+pg_sleep(5)--` 2. Send the request and notice the `pg_sleep(5)` command is executed with a time delay of 5 seconds in the response. This verifies that the SQL injection vulnerability exists.  ### PoC 2 - SQL Injection at saveentry 1....

### Summary A SQL injection vulnerability has been discovered in the the "Add News" functionality due to improper escaping of the email address. This allows any authenticated user with the rights to add/edit FAQ news to exploit this vulnerability to exfiltrate data, take over accounts and in some cases, even achieve RCE. ### Details The vulnerable field lies in the `authorEmail` field which uses PHP's `FILTER_VALIDATE_EMAIL` filter. This filter is insufficient in protecting against SQL injection attacks and should still be properly escaped. However, in this version of phpMyFAQ (3.2.5), this field is not escaped properly can be used together with other fields to fully exploit the SQL injection vulnerability. ### PoCs 4 PoCs are demonstrated here to illustrate the potential impacts. #### PoC 1 - Postgres Time Based SQLi 1. Login as admin or any user with the rights to view and save news. 2. Navigate to "../phpmyfaq/admin/?action=news", click on "Add news", fill in some data, send and...

### Summary Burn uses an unprotected C:\Windows\Temp directory to copy binaries and run them from there. This directory is not entirely protected against low privilege users. ### Details When a bundle runs as SYSTEM user, Burn uses GetTempPathW which points to an insecure directory C:\Windows\Temp to drop and load multiple binaries. Standard users can hijack the binary before it's loaded in the application resulting in elevation of privileges. icacls c:\windows\temp **BUILTIN\Users:(CI)(S,WD,AD,X)** BUILTIN\Administrators:(F) BUILTIN\Administrators:(OI)(CI)(IO)(F) NT AUTHORITY\SYSTEM:(F) NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F) CREATOR OWNER:(OI)(CI)(IO)(F) Built in users(non-administrators) have special permissions to this folder and can create files and write to this directory. While they do not have explicit read permissions, there is a way they can monitor the changes to this directory using ReadDirectoryChangesW API and thus figure out randomized folder names ...

### Impact WP Crontrol includes a feature that allows administrative users to create events in the WP-Cron system that store and execute PHP code [subject to the restrictive security permissions documented here](https://wp-crontrol.com/docs/php-cron-events/). While there is _no known vulnerability in this feature on its own_, there exists potential for this feature to be vulnerable to RCE if it were specifically targeted via vulnerability chaining that exploited a separate SQLi (or similar) vulnerability. This is exploitable on a site if one of the below preconditions are met: * The site is vulnerable to a writeable SQLi vulnerability in any plugin, theme, or WordPress core * The site's database is compromised at the hosting level * The site is vulnerable to a method of updating arbitrary options in the `wp_options` table * The site is vulnerable to a method of triggering an arbitrary action, filter, or function with control of the parameters ### Patches As a hardening measure, WP...

### Impact The vulnerability [CVE-2023-49090](https://github.com/carrierwaveuploader/carrierwave/security/advisories/GHSA-gxhx-g4fq-49hj) wasn't fully addressed. This vulnerability is caused by the fact that when uploading to object storage, including Amazon S3, it is possible to set a Content-Type value that is interpreted by browsers to be different from what's allowed by `content_type_allowlist`, by providing multiple values separated by commas. This bypassed value can be used to cause XSS. ### Patches Upgrade to [3.0.7](https://rubygems.org/gems/carrierwave/versions/3.0.7) or [2.2.6](https://rubygems.org/gems/carrierwave/versions/2.2.6). ### Workarounds Use the following monkey patch to let CarrierWave parse the Content-type by using `Marcel::MimeType.for`. ```ruby # For CarrierWave 3.x CarrierWave::SanitizedFile.class_eval do def declared_content_type @declared_content_type || if @file.respond_to?(:content_type) && @file.content_type Marcel::MimeType.for(d...

### Impact Versions of Express.js prior to 4.19.2 and pre-release alpha and beta versions before 5.0.0-beta.3 are affected by an open redirect vulnerability using malformed URLs. When a user of Express performs a redirect using a user-provided URL Express performs an encode [using `encodeurl`](https://github.com/pillarjs/encodeurl) on the contents before passing it to the `location` header. This can cause malformed URLs to be evaluated in unexpected ways by common redirect allow list implementations in Express applications, leading to an Open Redirect via bypass of a properly implemented allow list. The main method impacted is `res.location()` but this is also called from within `res.redirect()`. ### Patches https://github.com/expressjs/express/commit/0867302ddbde0e9463d0564fea5861feb708c2dd https://github.com/expressjs/express/commit/0b746953c4bd8e377123527db11f9cd866e39f94 An initial fix went out with `[email protected]`, we then patched a feature regression in `4.19.1` and added ...

### Impact Code that uses KaTeX's `trust` option, specifically that provides a function to block-list certain URL protocols, can be fooled by URLs in malicious inputs that use uppercase characters in the protocol. In particular, this can allow for malicious input to generate `javascript:` links in the output, even if the `trust` function tries to forbid this protocol via `trust: (context) => context.protocol !== 'javascript'`. ### Patches Upgrade to KaTeX v0.16.10 to remove this vulnerability. ### Workarounds * Allow-list instead of block protocols in your `trust` function. * Manually lowercase `context.protocol` via `context.protocol.toLowerCase()` before attempting to check for certain protocols. * Avoid use of or turn off the `trust` option. ### Details KaTeX did not normalize the `protocol` entry of the `context` object provided to a user-specified `trust`-function, so it could be a mix of lowercase and/or uppercase letters. It is generally better to allow-list by protocol, i...