Soosyze CMS 2.0 does not impose rate limiting or account-lockout controls on its authentication functionality. This permits an unauthenticated remote attacker to make unrestricted repeated credential guesses, enabling brute-force attacks against user accounts, including administrative accounts.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos (1 hidden).
Repository contains a small educational Bash proof-of-concept demonstrating automated brute-force against a web login form lacking basic defenses. Structure: - README.md: Explains the intent (educational), describes the brute-force flow (GET form, extract CSRF token, POST credentials, detect success), and suggests lab usage (e.g., DVWA). Also includes contact handles. - soosyze.sh: Main script implementing the attack. Key behaviors in soosyze.sh: - Targeting: Hardcoded defaults point to a local lab service: BASE_URL=http://localhost:8000 and LOGIN_PATH=/user/login, with fixed parameter names (email/password) and a fixed target account (test@test.com). - Session handling: Uses a curl cookie jar (mktemp) and reuses it for both GET and POST. - CSRF handling: Fetches the login page into /tmp/login_page.html and uses sed to locate a hidden input whose name contains 'token' or 'csrf', then extracts its value and includes it in the POST if found. - Brute-force loop: Iterates over either a provided wordlist file (first CLI arg) or a small built-in list of common passwords; adds a small random sleep (0.1–0.9s) between attempts. - Success condition: Treats the attempt as successful if the response body written to /tmp/resp.html contains the string '"redirect"' (not based on HTTP status alone). Overall purpose: Demonstrate how to automate credential guessing against a vulnerable login endpoint and why mitigations like rate limiting, lockout, CAPTCHA, and MFA are necessary.
7 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.