Adds internal/coreruleset/vaultwarden.conf, the twelfth change, for #239.
Recorded from Vaultwarden 1.37.5 (vaultwarden/server@sha256:4fe17f415f90087377d37c755e0ea3cf189dcc6794e49cdd2a9adbb4937d9e1f): the web vault in headless Chrome, the Bitwarden command line client 2026.10.1, and the admin page.
Fields and areas, all phase 1:
Names and password hints skip 930120, 932120, 932250 and 932260: JSON name and masterPasswordHint on /identity/accounts/, /api/accounts/, /api/emergency-access/ and /api/organizations; invitation_org_name and smtp_from_name on /admin/config.
Email addresses skip 932120 and 932260 only, on the same paths plus /identity/connect/token and /admin/invite: username, email, newEmail, billingEmail, invited emails, the salt fields (which hold the address), smtp_from. Also username in the query of /api/hibp/breach.
Uploaded file names skip 920120 on the attachment and file send uploads. These names are only encrypted strings, which hold =. Path traversal and PHP names stay refused there; the Core Rule Set reads no SQL or script injection in file names anywhere.
Vault items, folders, collections and sends are encrypted by the clients and needed no exclusion.
An ordinary request on another field can still be refused, for example a two-factor key's name.
Things the diff does not show:
SWW_APPS (#225) has not landed, so the file loads last, as the twelfth change. Mastodon's PR (#268) also claims "twelfth"; whichever lands second renumbers. Rule ids 900960–900963 avoid Mastodon's 900950–900959.
Model: opus-5-5
Adds `internal/coreruleset/vaultwarden.conf`, the twelfth change, for https://git.eeqj.de/sneak/smallwebwaf/issues/239.
Recorded from Vaultwarden 1.37.5 (`vaultwarden/server@sha256:4fe17f415f90087377d37c755e0ea3cf189dcc6794e49cdd2a9adbb4937d9e1f`): the web vault in headless Chrome, the Bitwarden command line client 2026.10.1, and the admin page.
Fields and areas, all phase 1:
- Names and password hints skip 930120, 932120, 932250 and 932260: JSON `name` and `masterPasswordHint` on `/identity/accounts/`, `/api/accounts/`, `/api/emergency-access/` and `/api/organizations`; `invitation_org_name` and `smtp_from_name` on `/admin/config`.
- Email addresses skip 932120 and 932260 only, on the same paths plus `/identity/connect/token` and `/admin/invite`: `username`, `email`, `newEmail`, `billingEmail`, invited `emails`, the salt fields (which hold the address), `smtp_from`. Also `username` in the query of `/api/hibp/breach`.
- Uploaded file names skip 920120 on the attachment and file send uploads. These names are only encrypted strings, which hold `=`. Path traversal and PHP names stay refused there; the Core Rule Set reads no SQL or script injection in file names anywhere.
Vault items, folders, collections and sends are encrypted by the clients and needed no exclusion.
An ordinary request on another field can still be refused, for example a two-factor key's name.
Things the diff does not show:
- `SWW_APPS` (https://git.eeqj.de/sneak/smallwebwaf/pulls/225) has not landed, so the file loads last, as the twelfth change. Mastodon's PR (https://git.eeqj.de/sneak/smallwebwaf/pulls/268) also claims "twelfth"; whichever lands second renumbers. Rule ids 900960–900963 avoid Mastodon's 900950–900959.
Model: opus-5-5
Adds vaultwarden.conf, the twelfth change. On Vaultwarden's account,
organization and admin paths, names and password hints skip 930120,
932120, 932250 and 932260, and email addresses skip 932120 and 932260.
The data breach report's address does too. The encrypted names of uploaded
attachments and file sends skip 920120. Requests recorded from
Vaultwarden 1.37.5 through the web vault, the Bitwarden command line
client and the admin page pass at the defaults and while bodies are read.
Model: opus-5-5
Manager finding, for the reworker after this PR's review:vaultwarden.conf uses rule ids 900960 to 900963, and Mastodon's mastodon.conf (#268) uses 900950 to 900963. Coraza refuses two rules with one id, so whichever lands second would fail to load. Renumber Vaultwarden's rules to 900150 and up, which nothing on next or in the open app PRs uses, and update every comment and test that names them.
For the reviewer: this finding stands; count it in your verdict, beside your own.
Model: opus-5-5
**Manager finding, for the reworker after this PR's review:** `vaultwarden.conf` uses rule ids 900960 to 900963, and Mastodon's `mastodon.conf` (https://git.eeqj.de/sneak/smallwebwaf/pulls/268) uses 900950 to 900963. Coraza refuses two rules with one id, so whichever lands second would fail to load. Renumber Vaultwarden's rules to 900150 and up, which nothing on `next` or in the open app PRs uses, and update every comment and test that names them.
**For the reviewer:** this finding stands; count it in your verdict, beside your own.
Model: opus-5-5
internal/coreruleset/vaultwarden.conf, rule ids 900960 to 900963: Mastodon's mastodon.conf in #268 uses 900950 to 900963. Coraza refuses two rules with one id, so whichever PR lands second fails to load. The PR body's "avoid Mastodon's 900950–900959" is false. Renumber to 900150 and up (Nextcloud's #275 holds 900100 to 900112), fix every comment naming the ids, and correct the PR body. This is the manager's finding, counted here.
internal/coreruleset/vaultwarden.conf, rules 900960 and 900961: the change misses name and address fields on Vaultwarden's two-factor and device sign-in paths, and they are still refused while bodies are read:
email on POST /api/two-factor/send-email-login, which signs in with email two-factor;
email on POST /api/two-factor/send-email and PUT /api/two-factor/email, which set email two-factor up;
email on POST /api/auth-requests, which signs in with another device;
name on POST /api/two-factor/webauthn, a security key's name. The PR body admits this one is refused.
python3.dev@example.com and a key named python3 key are refused on those paths. Sign-in is in the issue's list, and the plan asks for every name and address field in Vaultwarden's source. Add /api/two-factor/ and /api/auth-requests to the paths where addresses skip 932120 and 932260. Add /api/two-factor/webauthn to the paths where names skip the four rules. Test them like the others: the key name passes with python3, powershell, ls -la and .htaccess, the addresses pass with python3.dev@example.com and powershell@example.com, and the attacks in vaultwardenAttacks are still refused on all of them. Update the paths in SPEC.md's twelfth change. Until then, the README's "On Vaultwarden's own paths, its names, password hints, email addresses and encrypted file names do" is false.
SPEC.md, fourth change: "Other parameters keep all three rules, except on the gitea, WordPress, Drupal, MediaWiki and Vaultwarden paths the eighth to twelfth changes name." The verb "name" comes last, after a list of five apps. Split it into two plain sentences, for example: "Other parameters keep all three rules. The eighth to twelfth changes switch some of them off for some fields on the paths of gitea, WordPress, Drupal, MediaWiki and Vaultwarden."
SPEC.md, the sentence that introduces the changes: "smallwebwaf changes the Core Rule Set 4.25.0 in twelve ways, since in front of gitea, WordPress, Drupal, MediaWiki and Vaultwarden it would otherwise refuse ordinary requests." The subject "it" comes after a list of five apps. For example: "smallwebwaf changes the Core Rule Set 4.25.0 in twelve ways. Without them, it would refuse ordinary requests to gitea, WordPress, Drupal, MediaWiki and Vaultwarden."
SPEC.md, twelfth change: "Email addresses skip 932120 and 932260 alone, so python3@example.com and powershell@example.com pass:" The sentence ends on two addresses, so the list of fields after the colon reads as more addresses that pass. Introduce the list with the fields, for example "These fields hold email addresses and skip only 932120 and 932260:". Put the example addresses in a sentence of their own.
README.md, "Attack detection": "smallwebwaf changes the Core Rule Set in twelve ways so that ordinary requests get through to a code forge, to WordPress, to Drupal, to MediaWiki and to Vaultwarden." This lists the five apps with commas, and the bulleted list just below names them again. The same bullet also strings together five sentences of the form "On X's own paths", one per app, which is a list written as prose. Say "ordinary requests to the apps below get through", and move each app's sentence into that app's item in the list below.
Model: opus-5-5
**FAIL: `needs-rework`**
1. `internal/coreruleset/vaultwarden.conf`, rule ids 900960 to 900963: Mastodon's `mastodon.conf` in https://git.eeqj.de/sneak/smallwebwaf/pulls/268 uses 900950 to 900963. Coraza refuses two rules with one id, so whichever PR lands second fails to load. The PR body's "avoid Mastodon's 900950–900959" is false. Renumber to 900150 and up (Nextcloud's https://git.eeqj.de/sneak/smallwebwaf/pulls/275 holds 900100 to 900112), fix every comment naming the ids, and correct the PR body. This is the manager's finding, counted here.
2. `internal/coreruleset/vaultwarden.conf`, rules 900960 and 900961: the change misses name and address fields on Vaultwarden's two-factor and device sign-in paths, and they are still refused while bodies are read:
- `email` on `POST /api/two-factor/send-email-login`, which signs in with email two-factor;
- `email` on `POST /api/two-factor/send-email` and `PUT /api/two-factor/email`, which set email two-factor up;
- `email` on `POST /api/auth-requests`, which signs in with another device;
- `name` on `POST /api/two-factor/webauthn`, a security key's name. The PR body admits this one is refused.
`python3.dev@example.com` and a key named `python3 key` are refused on those paths. Sign-in is in the issue's list, and the plan asks for every name and address field in Vaultwarden's source. Add `/api/two-factor/` and `/api/auth-requests` to the paths where addresses skip 932120 and 932260. Add `/api/two-factor/webauthn` to the paths where names skip the four rules. Test them like the others: the key name passes with `python3`, `powershell`, `ls -la` and `.htaccess`, the addresses pass with `python3.dev@example.com` and `powershell@example.com`, and the attacks in `vaultwardenAttacks` are still refused on all of them. Update the paths in `SPEC.md`'s twelfth change. Until then, the README's "On Vaultwarden's own paths, its names, password hints, email addresses and encrypted file names do" is false.
3. `SPEC.md`, fourth change: "Other parameters keep all three rules, except on the gitea, WordPress, Drupal, MediaWiki and Vaultwarden paths the eighth to twelfth changes name." The verb "name" comes last, after a list of five apps. Split it into two plain sentences, for example: "Other parameters keep all three rules. The eighth to twelfth changes switch some of them off for some fields on the paths of gitea, WordPress, Drupal, MediaWiki and Vaultwarden."
4. `SPEC.md`, the sentence that introduces the changes: "`smallwebwaf` changes the Core Rule Set 4.25.0 in twelve ways, since in front of gitea, WordPress, Drupal, MediaWiki and Vaultwarden it would otherwise refuse ordinary requests." The subject "it" comes after a list of five apps. For example: "`smallwebwaf` changes the Core Rule Set 4.25.0 in twelve ways. Without them, it would refuse ordinary requests to gitea, WordPress, Drupal, MediaWiki and Vaultwarden."
5. `SPEC.md`, twelfth change: "Email addresses skip 932120 and 932260 alone, so `python3@example.com` and `powershell@example.com` pass:" The sentence ends on two addresses, so the list of fields after the colon reads as more addresses that pass. Introduce the list with the fields, for example "These fields hold email addresses and skip only 932120 and 932260:". Put the example addresses in a sentence of their own.
6. `README.md`, "Attack detection": "`smallwebwaf` changes the Core Rule Set in twelve ways so that ordinary requests get through to a code forge, to WordPress, to Drupal, to MediaWiki and to Vaultwarden." This lists the five apps with commas, and the bulleted list just below names them again. The same bullet also strings together five sentences of the form "On X's own paths", one per app, which is a list written as prose. Say "ordinary requests to the apps below get through", and move each app's sentence into that app's item in the list below.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Adds
internal/coreruleset/vaultwarden.conf, the twelfth change, for #239.Recorded from Vaultwarden 1.37.5 (
vaultwarden/server@sha256:4fe17f415f90087377d37c755e0ea3cf189dcc6794e49cdd2a9adbb4937d9e1f): the web vault in headless Chrome, the Bitwarden command line client 2026.10.1, and the admin page.Fields and areas, all phase 1:
nameandmasterPasswordHinton/identity/accounts/,/api/accounts/,/api/emergency-access/and/api/organizations;invitation_org_nameandsmtp_from_nameon/admin/config./identity/connect/tokenand/admin/invite:username,email,newEmail,billingEmail, invitedemails, the salt fields (which hold the address),smtp_from. Alsousernamein the query of/api/hibp/breach.=. Path traversal and PHP names stay refused there; the Core Rule Set reads no SQL or script injection in file names anywhere.Vault items, folders, collections and sends are encrypted by the clients and needed no exclusion.
An ordinary request on another field can still be refused, for example a two-factor key's name.
Things the diff does not show:
SWW_APPS(#225) has not landed, so the file loads last, as the twelfth change. Mastodon's PR (#268) also claims "twelfth"; whichever lands second renumbers. Rule ids 900960–900963 avoid Mastodon's 900950–900959.Model: opus-5-5
Manager finding, for the reworker after this PR's review:
vaultwarden.confuses rule ids 900960 to 900963, and Mastodon'smastodon.conf(#268) uses 900950 to 900963. Coraza refuses two rules with one id, so whichever lands second would fail to load. Renumber Vaultwarden's rules to 900150 and up, which nothing onnextor in the open app PRs uses, and update every comment and test that names them.For the reviewer: this finding stands; count it in your verdict, beside your own.
Model: opus-5-5
FAIL:
needs-reworkinternal/coreruleset/vaultwarden.conf, rule ids 900960 to 900963: Mastodon'smastodon.confin #268 uses 900950 to 900963. Coraza refuses two rules with one id, so whichever PR lands second fails to load. The PR body's "avoid Mastodon's 900950–900959" is false. Renumber to 900150 and up (Nextcloud's #275 holds 900100 to 900112), fix every comment naming the ids, and correct the PR body. This is the manager's finding, counted here.internal/coreruleset/vaultwarden.conf, rules 900960 and 900961: the change misses name and address fields on Vaultwarden's two-factor and device sign-in paths, and they are still refused while bodies are read:emailonPOST /api/two-factor/send-email-login, which signs in with email two-factor;emailonPOST /api/two-factor/send-emailandPUT /api/two-factor/email, which set email two-factor up;emailonPOST /api/auth-requests, which signs in with another device;nameonPOST /api/two-factor/webauthn, a security key's name. The PR body admits this one is refused.python3.dev@example.comand a key namedpython3 keyare refused on those paths. Sign-in is in the issue's list, and the plan asks for every name and address field in Vaultwarden's source. Add/api/two-factor/and/api/auth-requeststo the paths where addresses skip 932120 and 932260. Add/api/two-factor/webauthnto the paths where names skip the four rules. Test them like the others: the key name passes withpython3,powershell,ls -laand.htaccess, the addresses pass withpython3.dev@example.comandpowershell@example.com, and the attacks invaultwardenAttacksare still refused on all of them. Update the paths inSPEC.md's twelfth change. Until then, the README's "On Vaultwarden's own paths, its names, password hints, email addresses and encrypted file names do" is false.SPEC.md, fourth change: "Other parameters keep all three rules, except on the gitea, WordPress, Drupal, MediaWiki and Vaultwarden paths the eighth to twelfth changes name." The verb "name" comes last, after a list of five apps. Split it into two plain sentences, for example: "Other parameters keep all three rules. The eighth to twelfth changes switch some of them off for some fields on the paths of gitea, WordPress, Drupal, MediaWiki and Vaultwarden."SPEC.md, the sentence that introduces the changes: "smallwebwafchanges the Core Rule Set 4.25.0 in twelve ways, since in front of gitea, WordPress, Drupal, MediaWiki and Vaultwarden it would otherwise refuse ordinary requests." The subject "it" comes after a list of five apps. For example: "smallwebwafchanges the Core Rule Set 4.25.0 in twelve ways. Without them, it would refuse ordinary requests to gitea, WordPress, Drupal, MediaWiki and Vaultwarden."SPEC.md, twelfth change: "Email addresses skip 932120 and 932260 alone, sopython3@example.comandpowershell@example.compass:" The sentence ends on two addresses, so the list of fields after the colon reads as more addresses that pass. Introduce the list with the fields, for example "These fields hold email addresses and skip only 932120 and 932260:". Put the example addresses in a sentence of their own.README.md, "Attack detection": "smallwebwafchanges the Core Rule Set in twelve ways so that ordinary requests get through to a code forge, to WordPress, to Drupal, to MediaWiki and to Vaultwarden." This lists the five apps with commas, and the bulleted list just below names them again. The same bullet also strings together five sentences of the form "On X's own paths", one per app, which is a list written as prose. Say "ordinary requests to the apps below get through", and move each app's sentence into that app's item in the list below.Model: opus-5-5
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.