fix: add the missing capture group to four regex extractors

[DPS0340]

What's wrong

Four regex extractors declare group: 1 on a pattern that has no capture group. ExtractRegex skips every submatch (len(match) < group+1), so the value each template promises is never reported — silently, with no error.

http/exposed-panels/oracle-containers-panel.yaml                        version never extracted
http/misconfiguration/springboot/springboot-x-application-context.yaml  header value never extracted
http/exposures/configs/smtp-credentials-exposure.yaml                   JSON form of both credentials missed (x2)

smtp-credentials-exposure is the clearest. Two patterns share one group: 1, and only the XML form captures:

regex:
  - smtp_username":".*"                    # 0 capture groups  <- never extracts
  - <smtp_username>(.*)</smtp_username>    # 1 capture group

Against a body containing both forms it extracts only bob from the XML. The JSON credential — what the template is named for — goes unreported.

How these were found

Scanned all of nuclei-templates: 13,451 yaml files, 2,100 regex extractors with group > 0. These four are the only ones affected, and after this change the scan reports 0.

Verification

Each replacement was checked against a realistic corpus before proposing it:

template	pattern	extracts
oracle	Oracle Containers for J2EE 10g \((.*)\)	10.1.3.5.0
springboot	(?m)^X-Application-Context:\s*(\S.+)$	application:prod:8080
smtp user	smtp_username":"(.*?)"	admin
smtp pass	smtp_password":"(.*?)"	s3cr3t

All four currently extract nothing.

Two deliberate choices, both tested:

• (?m) on the springboot pattern. The header part is a multi-line block, so without it ^ only matches at the very start and the extractor still returns nothing — I confirmed that case: no (?m) -> [].
• Lazy .*? on the smtp patterns. With a greedy .*, a body containing several keys captures everything between the first and last quote:

  greedy .*  -> [admin","other":"x","smtp_username":"second]
  lazy .*?   -> [admin second]
  

End-to-end with nuclei: I built nuclei with the validation from projectdiscovery/nuclei#7612 + #7603, which turns this class into a hard error. The originals are rejected with an exact reason, and these fixed versions validate clean:

before:  regex extractor group 1 is out of range for pattern
         "Oracle Containers for J2EE 10g \(.*\)", which has 0 capture group(s)
after:   All templates validated successfully

Only the extractor patterns changed — matchers are untouched, including the word matcher in the springboot template that shares the same string.

Note

These are worth fixing regardless of whether that nuclei-side validation lands; they're wrong today and have been since they were written. If the maintainers prefer, the group: 1 could be dropped instead of adding the capture — but then the extractor would return the whole match rather than just the value, which reads like a different intent from what the author wrote.

[DPS0340]

Heads-up: the 🛠 Tests workflow on this PR is sitting at action_required, not failing — it needs the one-time "approve and run workflows" click that GitHub requires for a first-time contributor to this repo. Nothing is wrong with the change itself; the checks simply haven't started.

For what it's worth, I ran the equivalent locally against a nuclei build:

nuclei -validate -t <changed templates>
[INF] All templates validated successfully

and confirmed the yaml still parses across the full tree.

Happy to wait — just flagging it so the empty check list isn't read as a red build.