SPIP < 4.3.6 Authorization Bypass Leading to Content Disclosure
SPIP before 4.3.6, 4.2.17, and 4.1.20 allows unauthorized content disclosure in the private area. The application does not properly check authorization when displaying content of articles and sections (rubriques) in AJAX-loaded fragments, allowing an authenticated attacker to access restricted content. This vulnerability is not mitigated by the SPIP security screen.
SPIP before 4.3.6, 4.2.17, and 4.1.20 allows Cross-Site Scripting (XSS) in the private area. The content of the error message displayed by the 'transmettre' API is not properly sanitized, allowing an attacker to inject malicious scripts. This vulnerability is mitigated by the SPIP security screen.
SPIP before 4.2.15 allows Cross-Site Scripting (XSS) via crafted content in HTML code tags. The application does not properly verify JavaScript within code tags, allowing an attacker to inject malicious scripts that execute in a victim's browser.
Spip 4.1.10 Admin Account Spoofing via Malicious SVG Upload
Spip 4.1.10 contains a file upload vulnerability that allows attackers to upload malicious SVG files with embedded external links. Attackers can trick administrators into clicking a crafted SVG logo that redirects to a potentially dangerous URL through improper file upload filtering.
SPIP Bigup Multipart File Upload OS Command Injection
SPIP before 4.3.2, 4.2.16, and
4.1.18 is vulnerable to a command injection issue. A
remote and unauthenticated attacker can execute arbitrary operating system commands by sending a crafted multipart file upload HTTP request.
The porte_plume plugin used by SPIP before 4.30-alpha2, 4.2.13, and 4.1.16 is vulnerable to an arbitrary code execution vulnerability. A remote and unauthenticated attacker can execute arbitrary PHP as the SPIP user by sending a crafted HTTP request.
SPIP before 4.1.14 and 4.2.x before 4.2.8 allows XSS via the name of an uploaded file. This is related to javascript/bigup.js and javascript/bigup.utils.js.
ecrire/public/assembler.php in SPIP before 4.1.13 and 4.2.x before 4.2.7 allows XSS because input from _request() is not restricted to safe characters such as alphanumerics.
SPIP before 4.2.1 allows Remote Code Execution via form values in the public area because serialization is mishandled. The fixed versions are 3.2.18, 4.0.10, 4.1.8, and 4.2.1.
SPIP v4.1.5 and earlier was discovered to contain a SQL injection vulnerability via the _oups parameter. This vulnerability allows attackers to execute arbitrary code via a crafted POST request.
Spip Web Framework v3.1.13 and below was discovered to contain multiple SQL injection vulnerabilities at /ecrire via the lier_trad and where parameters.
Multiple cross-site scripting (XSS) vulnerabilities in the component /spip.php of Spip Web Framework v3.1.13 and below allows attackers to execute arbitrary web scripts or HTML.
SPIP 4.0.0 is affected by a remote command execution vulnerability. To exploit the vulnerability, an attacker must craft a malicious picture with a double extension, upload it and then click on it to execute it.
SPIP 4.0.0 is affected by a Cross Site Request Forgery (CSRF) vulnerability in ecrire/public/aiguiller.php, ecrire/public/balises.php, ecrire/balise/formulaire_.php. To exploit the vulnerability, a visitor must visit a malicious website which redirects to the SPIP website. It is also possible to combine XSS vulnerabilities in SPIP 4.0.0 to exploit it. The vulnerability allows an authenticated attacker to execute malicious code without the knowledge of the user on the website (CSRF).
SPIP 4.0.0 is affected by a Cross Site Scripting (XSS) vulnerability in ecrire/public/interfaces.php, adding the function safehtml to the vulnerable fields. An editor is able to modify his personal information. If the editor has an article written and available, when a user goes to the public site and wants to read the author's information, the malicious code will be executed. The "Who are you" and "Website Name" fields are vulnerable.
SPIP 4.0.0 is affected by a Cross Site Scripting (XSS) vulnerability. To exploit the vulnerability, a visitor must browse to a malicious SVG file. The vulnerability allows an authenticated attacker to inject malicious code running on the client side into web pages visited by other users (stored XSS).