Unauthenticated privilege escalation in the Datawiza Proxy Auth Plugin for WordPress lets a remote attacker forge the user-identity and role HTTP headers the plugin consumes and thereby create and authenticate as a WordPress administrator, giving full control of the site (CVSS 3.1 base 9.8, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). The disclosed affected range is 1.1.0 up to but not including 1.1.1, and the vendor has released 1.1.1 as the fix. Practical exploitability is topology-dependent: forged headers are only honored if externally supplied copies actually reach the plugin, so a correctly configured front-end proxy that strips or overwrites these headers blocks the attack. A public PoC reference exists but is not verified as working exploit code, and EPSS is low at 0.14% (3rd percentile) despite the maximal severity score, so the vulnerability.today decision label is act_now on the basis of impact rather than observed exploitation.
Snipe-IT 8.6.2 and earlier can re-admit deactivated accounts - including accounts with admin rights - through the Google SSO callback, because GoogleAuthController::handleGoogleCallback logged in whichever local user matched the incoming Google email as a username without enforcing the activated flag. The exposure is gated by deployment shape: Google SSO must be enabled, the instance must use email-as-username (or the targeted account must have an email-shaped username), the Snipe-IT account must already be deactivated, and the attacker must still hold a live, unrevoked Google Workspace identity for that address. Default installations that use the firstname.lastname username format are not affected because the username/email mismatch makes the lookup return NULL; this makes the bug primarily an offboarding-window and former-insider risk rather than anonymous external compromise, and it has been assigned an act_now priority. No public exploit code was identified at time of analysis, and the issue is fixed in Snipe-IT 8.6.3 via commit 5fea2fadc0.
An authentication bypass in Parse Server affects 8.x releases before 8.6.102 and 9.0.0 through 9.10.5-alpha.2 when an app is configured with a custom authentication adapter written as a subclass of the exported AuthAdapter class: Parse Server never invokes the subclass's validateSetUp, validateLogin, and validateUpdate methods and instead falls back to an inherited base-class default that accepts any authData. For any provider served by such an adapter, unauthenticated remote attackers can supply arbitrary authData to sign up, link an identity, log in as an existing user, or skip a custom adapter that implements an additional authentication factor, potentially gaining full account access and integrity over affected data. Apps using built-in adapters or custom adapters defined as plain objects are not affected, and no public exploit code was identified at time of analysis; the priority label from the reporting feed is act_now, reflecting that the impact is severe for the narrower population that matches the configuration prerequisite.