The SifG22 team showed me a flaw in Luxine's account access

// responsible disclosure report · 2026-10-11
[1]  password recovery flaw (F12) → account taken
[2]  Supabase service key via console (F12)
[3]  secret key ... luxine
// end of method
------------------------------------------------
[fix] login / accounts / comments ... DISABLED
[fix] new secret API keys ........... REGENERATING
[fix] RLS hardening in SQL .......... IN PROGRESS
▍

Digital security is one of those aspects of development that can go unnoticed until someone proves there is a problem. This week I lived it up close, and I want to tell it with full transparency.

First and most important, a message for anyone with a Luxine account: we are sorry for any worry this may have caused, but luckily nothing serious happened. The people behind it were a friendly team, the SifG22 team, with a purely preventive intent, and no personal data was leaked or used. As a precaution, while we fix it we have fully disabled sign-in, accounts, and comments. They will be back as soon as we finish reinforcing security.

What happened

The SifG22 team, whom I am friends with, stepped in on Luxine to show me there was a risk I needed to fix before it could turn into something bigger. It was not a malicious attack: it was a warning.

The method was simple, and that is exactly why it was revealing. From the browser console (the one that opens with F12) and using commands, they probed how the site behaved under the hood. From there they managed to change an account’s password using the login panel itself. Nothing more: no elaborate trick and no access to external servers were needed, just what anyone has in their browser.

Why it was possible

The browser console (F12) is a normal development tool: every visitor has it. The problem is not that it exists, but trusting the browser to behave. If a sensitive operation —like changing a password— is decided on the client side, someone can tamper with those calls from the console and bypass the checks.

The lesson is clear: critical operations must be verified on the server, never only in the interface. Hiding buttons or validating in the browser is not enough; the backend must check, on every request, that whoever makes it is authorized to do so. That is the main takeaway from this whole experience.

What I have disabled while I fix it

I did not want to gloss over what happened or let it slide. I preferred to cut off the affected surface at the root and warn the public. Right now:

• Sign-in and accounts: disabled. The login and account pages are temporarily out of service.
• Comments and moderation: disabled, because writing comments depended on the account system.
• Supabase connection: disconnected on both the frontend and the backend, so nothing can be read or written while the review lasts.
• Admin routes: removed from public service.

Was information leaked?

This question must be handled carefully. What was demonstrated is that an account’s password could be changed from the client, but that does not by itself allow concluding that data was extracted or that information was published. The SifG22 team is friends with me and kept their screenshots as evidence, without spreading anything.

I do not want to present as confirmed a leak that has not been proven. That is why the next step is to review the logs and establish what could have happened, before stating anything.

What I am reinforcing

The experience leaves a clear list of work, already underway:

• Server-side verification: that password changes and any sensitive operation are checked on the backend, not in the browser.
• Access flow: rebuild login and password recovery so they cannot be tampered with from the client.
• Sessions: review the authentication logs and close any session that might be compromised.
• Keys and data: rotate the secrets that need it, avoid exposing them in the frontend, and review the access policies in Supabase.

What I take away from this

Sometimes, having someone you trust point out a flaw is the best way to discover that your systems need more attention than you thought. I would rather have known this way, preventively, than have found out through a real incident.

A system’s security is not proven by claiming it is protected, but by verifying that its controls work when it truly matters —and on the right side, the server’s. Thank you for your understanding while we put everything in order.