Forem: Bruno Pinto

Four Spaces Before
Bruno Pinto — Tue, 10 Feb 2026 13:25:11 +0000

I was working on a Livewire component when every interaction started throwing 419 errors. CSRF token mismatch, on every click. The kind of thing that makes you question your setup immediately.

At first I assumed it was a Livewire issue. But then I noticed something stranger — every page refresh generated a new session ID. Sessions worked fine with `php artisan serve`, but the moment I switched to Herd, no cookies stuck. Each request was a clean slate.

The 419 errors were just a symptom. Laravel couldn't maintain sessions because the browser never received a cookie.

Chasing the usual suspects

I started with the .env file:

SESSION_DRIVER=redis
SESSION_LIFETIME=120
SESSION_DOMAIN=null
SESSION_SECURE_COOKIE=false

Redis was running, PHP could connect to it. I created a test route to confirm sessions worked at the PHP level — they did. Data was stored, but the browser never got the Set-Cookie header.

I checked DevTools. No laravel_session cookie. No Set-Cookie header at all.

I went through the usual list: cookie domain, HTTPS settings, session path, Redis connection. All fine. Switched to the file driver. Same result. Tried setting a cookie manually:

Route::get('/cookie-test', function () {
    return response('Test')
        ->cookie('test_cookie', 'test_value', 60);
});

Still no Set-Cookie header. At this point it clearly wasn't a Laravel config problem. Something was preventing PHP from sending cookies entirely.

The actual problem

The breakthrough came from a raw header() call:

Route::get('/header-test', function () {
    header('X-Custom-Test: working');
    // ...
});

PHP responded with: "Cannot modify header information — headers already sent", and pointed to routes/web.php:1.

Line 1 should just be <?php. I opened the file and there it was — the tag was indented. Four spaces sitting right there, plain as day. I just hadn't noticed.

Why it only showed up in Herd

The bug existed all along. php artisan serve has output buffering enabled by default, so those spaces never reached the browser before the headers. The problem was silently masked.

Herd uses nginx + PHP-FPM with output_buffering = 0. Output goes out immediately. Those four spaces hit the browser before Laravel could send any headers — which meant no cookies, which meant no sessions.

The fix

Delete four spaces. That's it.

I made sure routes/web.php started with <?php on the very first character of the very first line. Saved. Everything worked.

Livewire relies on the session to verify CSRF tokens on every request. Without a Set-Cookie header, the browser never stores a session — and without a session, every Livewire interaction fails with a 419.

Four spaces before <?php were enough to start the response body, and once the body starts, PHP can't send headers anymore.

Vector: Vue in Blade, the easy way

Bruno Pinto — Tue, 03 Feb 2026 19:13:10 +0000

You know that feeling when you're building a Laravel app and you just need a tiny bit of reactivity? A counter. A toggle. Something that feels overkill for a full Vue component but too annoying for vanilla JavaScript?

I kept reaching for Alpine.js, which is great, but I wanted Vue's Composition API. The ref(), the computed(), the familiar syntax I already know. So I bu4ilt Vector.

What Even Is This?

Vector is a Laravel package that lets you write Vue directly in your Blade templates with zero ceremony:

<script setup>
    const i = ref(0);
</script>

<div>
    <button @click="i++">Click Me</button>
    <div>
        Count: @{{ i }}
    </div>
    <div v-if="i > 5">Success!</div>
</div>

That's the whole thing. No build step for your components. No separate .vue files. No special directives wrapping your code. Just a <script setup> tag and you're done.

How It Works

The <script setup> tag gets transformed at compile time. Vector treats the element immediately after the script tag as your Vue template. Everything inside that element becomes reactive, and anything outside it remains regular Blade.

Blade's precompiler finds your <script setup> blocks
Extracts your variable declarations
Mounts Vue on the next sibling element

The key part is the variable extraction. It parses const, let, and var declarations and auto-returns them to the template. You write normal code, it figures out the rest.

Escaping Blade Syntax

Since Blade also uses {{ }} for output, you need to prefix Vue's mustache syntax with @ to prevent Blade from processing it:

{{-- This is Blade --}}
{{ $phpVariable }}

{{-- This is Vue (note the @) --}}
@{{ vueVariable }}

Alternatively, use Vue directives like v-text which don't conflict with Blade:

<span v-text="count"></span>

Installation

composer require brunoabpinto/vector

Add Vector to your Vite entry points in vite.config.js:

plugins: [
    laravel({
        input: [
            "resources/css/app.css",
            "resources/js/app.js",
            "resources/js/vendor/vector.js",
        ],
        // ...
    }),
],
resolve: {
    alias: {
        'vue': 'vue/dist/vue.esm-bundler.js',
    },
},

Add @vectorJs before your closing </body> tag in your layout:

<body>
    {{ $slot }}

    @vectorJs
</body>

That's it. Vector auto-publishes its runtime, and @vectorJs loads it where you need it.

The Trade-offs

Let's be real about what this is:

Good for:

Quick interactive elements
Prototyping
When you want Vue's API without Vue's ceremony
Laravel apps that are mostly server-rendered with islands of reactivity

Not great for:

Complex component hierarchies
When you need proper SFC features (scoped styles, etc.)
Large-scale SPAs (just use Inertia at that point)

Try It

The package is available on GitHub. Star it, fork it, tell me it's an abomination. Whatever feels right.

composer require brunoabpinto/vector

I Turned Images Into 10,000 Tiny HTML Elements Because Why Not

Bruno Pinto — Thu, 29 Jan 2026 12:41:30 +0000

Sometimes the best projects are the ones that solve problems nobody has.

Last weekend, I found myself staring at my screen, thinking about images. Not in a productive way. Not "how can I optimize image loading" or "what's the best format for web." No, I was thinking something far more unhinged:

What if every pixel was just a tiny HTML element?

And thus, IMGML was born.

The Premise

Here's the concept: take an image, read it pixel by pixel, and generate an HTML file where each pixel is represented by a 1x1 <hr> element with a background color matching the original pixel.

That's it. That's the whole thing.

No <img> tags. No <canvas>. No SVG. Just thousands upon thousands of microscopic horizontal rules, arranged in a grid, pretending to be an image.

Does It Work?

Technically? Yes.

Practically? That's a strong word.

Upload a 100x100 pixel image and you get 10,000 HTML elements. A 200x200 image? 40,000 elements. Your browser will render it. Your browser might also ask you why you've done this.

But here's the thing — it does look like the image. Open the HTML file and there it is, your photo, reconstructed entirely from styled <hr> tags. It's beautiful in the way that a Rube Goldberg machine is beautiful. Unnecessarily complex, deeply impractical, and yet somehow satisfying.

Why Though?

I get asked this a lot. "Why would you do this?" "What's the use case?" "Are you okay?"

The answers are: because I could, there isn't one, and debatable.

This is a "what if" project. It exists in that space between curiosity and questionable judgment. The space where you wonder "can I do this?" before asking "should I do this?"

Some might call it a waste of time. I call it a learning experience wrapped in absurdity.

The Tech

For those curious, it's built with Laravel 12 and Livewire. Upload an image, the backend processes it pixel by pixel, and you download your freshly minted HTML monstrosity.

Here's what the output looks like — just a wall of <hr> tags, each with an inline background color:

<r>
  <hr style="background:#cad5d9" />
  <hr style="background:#c5ced3" />
  <hr style="background:#cdd6db" />
  <hr style="background:#dde4ea" />
  <hr style="background:#e4ebf1" />
  <hr style="background:#e1e6ec" />
  <hr style="background:#dadfe5" />
  <hr style="background:#d7dadf" />
  ...
</r>

The Optimization Rabbit Hole

Once I committed to this absurd idea, I became obsessed with making each pixel as small as possible. Here's how that went:

Attempt 1: RGB

<hr style="background:rgb(255, 255, 255)">

Works, but verbose. All those characters add up.

Attempt 2: Hex

<hr style="background:#c5ced3"/>

Shorter. Hex codes are more compact than RGB.

Attempt 3: Drop the self-closing slash

<hr style="background:#c5ced3">

It's optional in HTML5. Every byte counts.

Attempt 4: Drop the quotes

<hr style=background:#c5ced3>

Also valid HTML. We're getting minimal.

Attempt 5: The bgcolor attribute

<hr bgcolor="#c5ced3">

Deprecated, and for some reason only works on <body>. Dead end.

Attempt 6: The color attribute

<hr color=#c5ced3>

This works. It's deprecated, it's not recommended, and it's perfect for this project.

Attempt 7: Drop the hashtag

<hr color=c5ced3>

Turns out the # is optional on hex colors. One more character gone.

This is the shortest I could make each pixel. If you know a way to make it smaller, I'm genuinely curious.

The code is straightforward. PHP's image functions handle the pixel reading:

// Resize to keep things manageable
$image = $this->resizeImage($path, 200, 200);
$resource = imagecreatefromjpeg($image);

$width = imagesx($resource);
$height = imagesy($resource);
$pixels = [];

// Loop through every pixel
for ($y = 0; $y < $height; $y++) {
    for ($x = 0; $x < $width; $x++) {
        // Get color index at this coordinate
        $color = imagecolorat($resource, $x, $y);

        // Convert to RGB array
        $rgb = imagecolorsforindex($resource, $color);

        // Format as hex (no hashtag needed)
        $hex = sprintf('%02x%02x%02x', $rgb['red'], $rgb['green'], $rgb['blue']);

        $pixels[] = $hex;
    }
}

Loop through each row, each column, grab the color, convert to hex, done. Livewire handles the upload/download flow. Nothing revolutionary — just reasonable tools applied to an unreasonable idea.

What I Actually Learned

Despite the silliness, building IMGML reminded me of a few things:

Constraints breed creativity. Limiting myself to just HTML elements forced me to think differently about rendering.
Performance matters everywhere. Processing images pixel by pixel taught me to respect the work that actual image libraries do.
Side projects don't need purpose. Not everything has to ship, scale, or solve a real problem. Sometimes you just build something weird and smile.

Should You Use This?

Absolutely not.

Well, maybe. If you need to:

Confuse a web developer
Create the world's least efficient image format
Prove a point about HTML being turing complete (it's not, but this feels adjacent)
Kill time on a Saturday

Then yes, IMGML is for you.

Try It Yourself

The project is open source. Clone it, run it, upload an image, and watch your browser question its life choices as it renders your photo one <hr> at a time.

Will it change the world? No.

Will it make you briefly happy in a "wow, that's dumb" kind of way? Almost certainly.

And sometimes, that's enough.

Here's my GitHub avatar in IMGML format if you want to see it in action.

Note:
<hr color="c5ced3" />
Does not work on Firefox. This example uses the following structure:
<hr style="background:#07040b" />

IMGML is available on GitHub. Star it if you appreciate the absurdity.

Solving Livewire's 419 After Session Expiration

Bruno Pinto — Thu, 22 Jan 2026 19:53:39 +0000

The Problem

If you've worked with Livewire in Laravel applications, you've probably encountered this frustrating scenario: a user is actively working in your application, filling out a long form or interacting with components, when suddenly—BAM! A 419 error appears, and all their work is lost. The dreaded "CSRF token mismatch" strikes again.

This happens because Laravel's session expires (typically after 120 minutes by default), invalidating the CSRF token. When the user tries to interact with a Livewire component after this expiration, Laravel rejects the request for security reasons. The user is forced to refresh the page manually and start over.

Not a great user experience.

Why This Happens

Laravel's CSRF protection is essential for security—it prevents cross-site request forgery attacks by ensuring requests come from your application. Each session gets a unique CSRF token that's validated on every state-changing request.

When a session expires:

The CSRF token in the user's browser becomes stale
The server generates a new token for the new session
Any Livewire action sends the old, invalid token
Laravel returns a 419 status code
User frustration ensues

While Livewire does handle this with a page-expired event, it typically just shows an error or reloads the page—still losing user data.

The Solution: Automatic CSRF Token Refresh

I built a simple Laravel package that silently refreshes the CSRF token in the background before the session expires, preventing the 419 error entirely. The user never knows it's happening—they just keep working without interruption.

The package:

Automatically calculates the refresh interval based on your session lifetime
Fetches a fresh CSRF token via AJAX
Updates the meta tag in the DOM
Works seamlessly with Livewire and all Laravel applications
Requires zero configuration

Installation

Install via Composer:

composer require brunoabpinto/csrf-refresh

The package automatically:

Publishes the JavaScript file to public/vendor/csrf-refresh/
Registers the refresh route
Registers the @csrfRefresh Blade directive

Usage

Just add one line to your layout file:

<!DOCTYPE html>
<html>
<head>
    <meta name="csrf-token" content="{{ csrf_token() }}">
    <title>My App</title>
</head>
<body>
    {{ $slot }}

    @csrfRefresh
</body>
</html>

That's it! Your CSRF tokens will now refresh automatically before the session expires.

How It Works

The package does four things:

1. Calculates the Refresh Interval

Based on your config/session.php lifetime setting, the package calculates when to refresh the token—50 seconds before expiration by default:

$interval = (config('session.lifetime') * 60 - 50) * 1000; // in milliseconds

2. Registers a Refresh Endpoint

A simple route that returns a fresh CSRF token:

Route::get('/csrf-token/refresh', function () {
    return response()->json(['token' => csrf_token()]);
})->middleware('web')->name('csrf.refresh');

3. Injects Minified JavaScript

The @csrfRefresh directive injects:

The calculated interval as a global variable
A minified script that runs in the background

4. Silently Updates the Token

The JavaScript periodically fetches a new token and updates the meta tag:

async function refreshCsrfToken() {
  try {
    const response = await fetch("/csrf-token/refresh", {
      method: "GET",
      headers: {
        "X-Requested-With": "XMLHttpRequest",
        Accept: "application/json",
      },
    });

    if (response.ok) {
      const data = await response.json();
      const metaTag = document.querySelector('meta[name="csrf-token"]');

      if (metaTag && data.token) {
        metaTag.setAttribute("content", data.token);
      }
    }
  } catch (error) {
    console.warn("Failed to refresh CSRF token:", error);
  }
}

setInterval(refreshCsrfToken, refreshInterval);

Why I Built This as a Package

Initially, I was copying and pasting this solution across multiple projects. Every time I started a new Laravel/Livewire application, I'd recreate the same JavaScript, the same route, the same logic.

By packaging it, I can now:

Install once: composer require brunoabpinto/csrf-refresh
Add one directive: @csrfRefresh
Forget about it: It just works

It's saved me countless hours and eliminated a frustrating user experience issue across all my projects.

Benefits

No more 419 errors after session expiration
Zero configuration needed
Automatic refresh before expiration
Works with Livewire, Inertia, and traditional Laravel apps
Minimal overhead (one AJAX request per hour)
Reusable across projects

Conclusion

If you're building Livewire applications (or any long-running Laravel sessions), silent CSRF token refresh is a must-have for good UX. Instead of forcing users to refresh and lose their work, let this package handle it automatically in the background.

Check it out on GitHub or install it now:

composer require brunoabpinto/csrf-refresh

How a Livewire Vulnerability Led to Crypto Mining on Our Servers

Bruno Pinto — Thu, 22 Jan 2026 18:17:53 +0000

Last week, we experienced a security incident that started as a performance issue and turned into a crypto mining investigation. Here's what happened and what you need to know if you're running Livewire in production.

The Initial Signs

Pages were loading slowly, and Livewire components were lagging. Our initial investigation pointed to pending PHP-FPM processes consuming server resources, coinciding with a recent deployment. We killed the processes, and everything seemed back to normal.

Or so we thought.

The Real Problem Emerges

Within hours, the server was slow again. CPU usage spiked to nearly 100% between 1:00 PM and 1:30 PM. This time, deeper investigation revealed something more sinister—a suspicious process running on the server:

apps 376184 547 13.9 4658672 4581484 ? Sl 12:46 268:46 \_ /var/www/apps/website/releases/1768928757/storage/stmept --url pool.supportxmr.com:3333 --user 8556M2fMqE8Dg1U3pERP9rJ64jaa6MMha5SY5ovWQ7XiYjxdKquPQ7Z4afpEeXUtfJVBLGvLncGxtKMugv61S9nFGMHNAFK --pass next --donate-level 0

The site had been compromised. Malicious files had been injected for Monero cryptocurrency mining.

The Malware Arsenal

We discovered multiple malicious files scattered across the application:

In the storage directory:

gd.py
guard.sh
stmept
wp-admin.php

In the public directory:

339a36afe37df27417e6c26b684845d4.lock
Multiple suspicious PHP files: 4hpce7mz.php, 9hb1pmgk.php, klhrqd7x.php, wp-admin.php

The most persistent was the stmept binary—it would reappear within a minute of deletion, even after fresh deployments.

The Week Before

In retrospect, the warning signs were there. A week earlier, other of our content websites had experienced a hack with remote execution file injection. We cleaned it up, and the files didn't return. We only noticed it because attackers had wiped the index.php, leaving the site blank. At the time, we couldn't identify the entry point.

The Investigation

Working with our hosting provider, we tried everything:

Modified request validators in the code
Reviewed all installed packages
Used AI agents to search for backdoors
Killed processes and deployed fresh releases

Nothing worked. The malware kept coming back.

Then, a Google search led us to this article, which described an identical scenario.

The Root Cause: CVE-2025-54068

The culprit was CVE-2025-54068, a remote code execution vulnerability disclosed in April 2025 affecting Livewire versions prior to 4.0. This vulnerability allows attackers to run arbitrary commands on your server simply by sending malformed requests.

We were running Livewire 3.5 across multiple projects.

All were vulnerable.

The Solution

We updated all projects to Livewire 4.0 via composer update. Since the update, the malware has not returned, and server performance has been stable.

Lessons Learned

Update immediately: If you're running any version of Livewire older than 4.0, update now. This is a critical remote code execution vulnerability.
Monitor for unusual processes: Regular server monitoring could have caught the crypto mining earlier.
Don't dismiss related incidents: The previous week's hack was a warning sign we didn't fully investigate.
Performance issues can be security issues: What started as a "slow website" complaint was actually an active breach.

Action Items

If you're running Livewire in production:

Check your Livewire version: composer show livewire/livewire
If you're on any version before 4.0, update immediately
Check for suspicious files in your storage and public directories
Review server processes for unusual CPU consumption

Originally published on my blog.

If you found this helpful, please share it with other Livewire users. This vulnerability is serious and widespread awareness is crucial.