Brute-force attempts against a Supabase database
A failed application sign-in targets a user account, while a rejected direct database login concerns a database credential. Defencecore surfaces suspicious database authentication activity so teams can investigate unknown access attempts and stale production secrets quickly.
Defencecore monitors supported Supabase database activity for rejected authentication patterns that may indicate credential guessing or unauthorized connection attempts. The alert provides the available connection context without claiming that an intrusion succeeded.
The same activity can be caused by a deployment, migration, connection pool, or operator using an obsolete secret. Responders should verify the origin and review nearby database activity before deciding whether the event is malicious.
What Defencecore watches for
- Rejected attempts to authenticate directly to the database.
- Suspicious repetition or sensitive database context that increases urgency.
- Connection details that help distinguish known infrastructure from an unknown origin.
Why the event matters
A direct database credential can carry broader authority than an application user account, so unexplained rejected connections deserve timely review.
Operational failures matter too: an obsolete secret can interrupt deployments or production services and shows that an old credential still exists somewhere in the environment.
What customers see
- The available database and connection context associated with the rejection.
- A timeline and representative Supabase events for the investigation.
- The affected database identity when that information is present in the source event.
How to interpret the detection
- A rejected database login does not mean the credential worked or the database was accessed.
- A legitimate service using an outdated secret can look similar to an unauthorized attempt.
- The source event can only contain the context exposed by the connected Supabase project.
First response
- Determine whether the connection belongs to a deployment, migration, pooler, team member, or other known system.
- Review nearby successful connections and database activity for unexpected behavior.
- For an unknown origin, restrict access and rotate the affected credential according to your incident process.
- For a known origin, update the obsolete secret and remove every stale copy.