ghsa

thorsten/phpmyfaq prior to 3.1.12 is vulnerable to improper access control when FAQ News is marked as inactive in settings and have comments enabled, allowing comments to be posted on inactive FAQs. This has been fixed in 3.1.12.

thorsten/phpmyfaq prior to 3.1.12 is vulnerable to DOM cross-site scripting (XSS) because it fails to sanitize user input in the configuration privacy note URL parameter. This has been fixed in 3.1.12.

thorsten/phpmyfaq prior to 3.1.12 is vulnerable to cross-site scripting (XSS) because it fails to sanitize user input in the `stopword` parameter. This has been fixed in 3.1.12.

thorsten/phpmyfaq prior to 3.1.12 is vulnerable to stored cross-site scripting (XSS) because it fails to sanitize user input in the artlang parameter. This has been fixed in 3.1.12.

thorsten/phpmyfaq prior to 3.1.12 is vulnerable to stored cross-site scripting (XSS) because it fails to sanitize user input in the adminlog. This has been fixed in 3.1.12.

thorsten/phpmyfaq prior to 3.1.12 is vulnerable to stored cross-site scripting (XSS) because it fails to sanitize user input in the FAQ site while generating an HTML Export. This has been fixed in 3.1.12.

MyBatis-Plus below 3.5.3.1 is vulnerable to SQL injection via the tenant ID value. This may allow remote attackers to execute arbitrary SQL commands.

In LangChain through 0.0.131, the `LLMMathChain` chain allows prompt injection attacks that can execute arbitrary code via the Python `exec()` method.

markdown-pdf version 11.0.0 allows an external attacker to remotely obtain arbitrary local files. This is possible because the application does not validate the Markdown content entered by the user.

### Summary The SvelteKit framework offers developers an option to create simple REST APIs. This is done by defining a `+server.js` file, containing endpoint handlers for different HTTP methods. SvelteKit provides out-of-the-box cross-site request forgery (CSRF) protection to it’s users. The protection is implemented at `kit/src/runtime/server/respond.js#L52`. While the implementation does a sufficient job in mitigating common CSRF attacks, the protection can be bypassed by simply specifying a different `Content-Type` header value. ### Details The CSRF protection is implemented using the code shown below. ```js const forbidden = // (1) request.method === 'POST' && // (2) request.headers.get('origin') !== url.origin && // (3) is_form_content_type(request); if (forbidden) { // (4) const csrf_error = error(403, `Cross-site ${request.method} form submissions are forbidden`); if (request.headers.get('accept') === 'application/json') { return json(csrf_error.body, {...