Feb 11, 2026

27

OP

Level 63

Attacks on a personal project developed with Livewire

Hello,

For some hours, a personal project is attacked and the logs give me this message.

[2026-02-09 15:36:56] production.ERROR: Class "Laravel\Prompts\Terminal" not found {"exception":"[object] (Error(code: 0): Class \"Laravel\\Prompts\\Terminal\" not found at /homepages/2/d877403005/htdocs/
miam/vendor/livewire/livewire/src/Features/SupportModels/ModelSynth.php:60)

It has been developed with Laravel v10 and Livewire v3.

The hacker has copied some files in the public folder and in the storage folder.

Is there any risk that the .env file has been visited too ? I don't think so.

Is it a problem with my webhosting ? I don't have to configure anything on it, it's a shared webhosting and I just have to copy the files with SSH. The structure of the project is exactly the same as the standard one for each Laravel project and the domain name points to the public folder.

Is it possible that the problem is related to a security breach from Laravel ?

It's on a personal project, so it's not so serious, but it's a good experience.

I have never been attacked on a Laravel project, so what do you suggest me to do ?

Thanks for your help.

V

AI

Level 58

It looks like attackers exploited your app to upload files into public and storage—this means your app (or shared hosting server) is likely misconfigured, not that Laravel or Livewire itself is vulnerable out of the box. Make sure you:

Don't allow public/guest file uploads unless necessary, and always validate uploads.
Set permissions: storage and public should NOT be world-writable. On shared hosting, you might not have full control, and that's risky.
.env file: By default, it should not be web-accessible. Try accessing your-site.com/.env—if you see anything, your server is misconfigured. .env should never be in the public web root.
Update everything: Make sure your Laravel, Livewire, and PHP versions are up-to-date.
Clean up: Delete any files the attacker placed, and check for backdoors (random PHP files in public or storage).
Consider moving to better hosting—shared hosting often can't properly secure web apps.

If you're curious how the "Laravel\Prompts\Terminal not found" happens: that's from Livewire or another package trying to use Laravel Prompts, which may be missing or autoloaded badly due to the attack or server state. But the main risk here is file uploads and permissions. Beef those up ASAP!

1 like

Level 50

If they're really able to execute arbitrary code, and this isn't just a bug in your code, then they absolutely have your .env contents. Not only can they read the file, they can read the config array or just call getenv() to get all environment variables. They can also scan the disk and read, write to, or execute any files the web server user can.

Environment values are usually the first thing attackers go for.

If I were you, I'd close the site until I've figured out the attack vector and fixed the vulnerability. And rotated all API keys and credentials used by the site.

I don't use Livewire, but I remember a major vulnerability was discovered a while ago. You should check if your packages are vulnerable by running composer audit.

Another possibility is that the site is deployed insecurely.

If this is just a personal project and it doesn't process other people's personal data, you probably don't have any legal obligations. Otherwise, I recommend checking article 33 of GDPR and any associated national laws.

P.S. Laravel 10 is EOL and hasn't received security updates in a while.

1 like

OP

Level 63

No legal obligations, I'm the only user of this application.

I don't think that the application is deployed unsecurely.

Level 30

Is there any risk that the .env file has been visited too ?

100% yes, this is the main purpose for such attacks.

what do you suggest me to do ?

Change all passwords/tokens, update Laravel and all packages (and keep them updated), contact hosting support.

1 like

Level 80

Is there any risk that the .env file has been visited too ? I don't think so.

@vincent15000 If someone is running arbitrary commands on your server and moving files around, why on earth do you think they wouldn’t have visited your .env file?

If they’re moving files around then I can guarantee they’ll have moved your .env to a web-accessible folder such as your public directory, and downloaded it already. And if there are things like AWS or Stripe keys in there, then you’re about to be pwned if you haven’t been already.

Change all the keys and secrets in that file. Upgrade packages. And check each and every service you have a key/secret for in your .env file, to ensure suspicious requests haven’t already been made. Otherwise you could be in for a nasty shock when your next bill comes in…

1 like

OP

Level 63

I think this because files are copied only inside the public folder.

OP

Level 63

That's probably why they can send emails with my trash email account on gmail. I have setup a code (not the password, but a code) to use this email account from a web application.

OP

Level 63

I'm not worried about any token exposed, I don't have any one except for the database and it's only for one database (all credentials for all databases are different, different user, different name, ...).

Level 75

Can you show your file upload code? That can open a hole if not secure.

1 like

OP

Level 63

I don't understand ... my file upload code ?

Hmmm ... the code is retrieve directly from gitlab.

But I'm not sure to understand what you mean ...

I have a unique file upload to add an image for a recipe.

public function saveMedia()
{
    $tmp = $this->media->temporaryUrl();
    $this->recipe->addMedia($this->media->path())->toMediaCollection();
    $this->media = null;
    $this->recipe->refresh();
}

It's inside a Livewire component and I just noticed that I don't have protected this action with Gate::authorize() and any validation rule. I do it always, but I have forgotten this time. Probably I'm less attentive with my personal projects.

But the component can't be accessed by not authenticated users. And I am the only user of the application.

I have checked the database, but I don't have seen anything strange inside.

Level 30

If you have SSH open to the world with weak password or improperly configured web server then no matter how many auth gates and validations you have in your app. An attacker won't even interact with Laravel and your app, gaining access through other holes.

1 like

OP

Level 63

Sure ... except perhaps the validation rule ...

I don't think that there is any problem with SSH, other websites would have been attacked too and it's not the case.

But for prevention I have changed all access tokens.

Level 50

Did you run composer audit or update packages?

1 like

OP

Level 63

Yes sure, it's the first think I have done in addition to changing access tokens.

OP

Level 63

I have called the webhosting and ... sure they refuse to give me the connection logs.

But they sent me an email with all suspicious files and I have deleted all these.

Then I have changed the ssh keys and all passwords.

For the moment I don't have any new attack.

I really think there wasn't any problem with Laravel, but probably any misconfiguration on the servers, but I can't configure anything, it's a shared webhosting. But perhaps I'm wrong ...

Level 75

Do you have main laravel one level higher that public_html? Only public folder should be exposed to the web.

1 like

OP

Level 63

The webhosting works like this.

I have a root folder for my account. I create the folder project with exactly the same structure as a standard Laravel project.

Then I can configure my domain to point it to the public folder of the application.

1 like

Level 75

As long as public is the only thing exposed to the web.

1 like

OP

Level 63

Yes it is.

The root folder is not exposed.

Best Answer

Level 1

Please be careful! I was attacked with a similar pattern and the attacker gained remote execution, the attacker used these CVEs

GHSA-29cq-5w36-x7w3
CVE-2024-47823 search them online to understand!

Please scan your files and your VPS for aunothorized access or files: do these immedietly:

scan for any directory with name: ALPHA_DATA
check your cron tab (under the user running the web server) for any payload.
check for access logs and current active connections from these bot IPs: 45.148.244.66,23.94.95.228,182.255.1.186,210.57.216.4
check for any process with name '[ksmd]' that is NOT running as 'root' user
check for processes with name 'defunc'

If you find anomalies i recommend you scrap the whole VPS and buy new one.

2 likes

OP

Level 63

Thank you for your advice.

I don't have a VPS, as I said in my post, it's a simple shared webhosting, so I can't do all these configurations.

But all is solved now, I don't have any attack anymore.

OP

Level 63

Effectively the only application that was attacked is the one developed with full Livewire.

Level 30

You don't see attacks doesn't mean there are no attacks :)

2 likes

OP

Level 63

Yes, sure.

The attacked application had a defunc file and some php files in the public directory. All unwished files are now deleted.

I have read all available logs and all seems to be ok now ;).

Level 3

That deep, I have no clue if someone is attacking my app. In past I have hired someone to look into my app. I guest it time to review the security with some of the Laracast Courses

You don't see attacks doesn't mean there are no attacks :)

1 like

Level 11

Try updating from time to time especially if you run your app on a shared hosting.

2 likes

OP

Level 63

Yes good idea ;).

Please or to participate in this conversation.