Change Priority of Server-Side Injection > Content Spoofing > HTML Content Injection from P5 to P4

[rootThatBox]

Hi team,
most of the time, the Impact of HTML injection can be more than informative or a P5 therefore I believe the severity here shall be P4
at the minimum, the impact here can include

• The attacker steals the victim's IP by embedding an image.
• Phishing
• Exploitation of GET based CSRF etc

also, we already have
Server-Side Injection > Content Spoofing > Email HTML Injection
as P4, so it would make more sense to change this to a P4 as the severity here shall be higher or equal to the Email HTML Injection issue

( in HTML Content Injection there are more attack scenarios and direct impact on the application.)

[TimmyBugcrowd]

Hi @rootThatBox

We believe this should stay P5 because it can't be directly exploited and mostly just changes how things look, not how they work. The attack scenarios mentioned (IP logging, phishing, and GET-based CSRF) rely on additional user interaction or misconfigurations rather than inherent application weaknesses. Additionally, modern security controls like CSP and input sanitization already mitigate most cases.

Let me know what you think!

[nightpool]

Exploitation of GET based CSRF would be a separate vulnerability I think—it wouldn't be appropriate to call that HTML content injection. However, the idea of a GET-based endpoint vulnerable to CSRF is definitely not a given, and it relies on the researcher putting in the work to identify those endpoints. So I think it's fair to say that you shouldn't just consider content injection a vulnerability because some apps might be vulnerable to GET-based "same site request forgery".

The risk of phishing is very hard to determine generically for all applications. However, most developers will consider phishing using images as out of scope for bug bounties, since it relies on further user input. Certainly link / header based phishing.

Similarly, I think most developers running bug bounties will probably consider "IP disclosure" as out of scope (and in fact there are some sites that provide this as a feature, like LiveJournal/Dreamwidth). However I could see an argument for considering it a separate vulnerability as well, and allowing the program owners to determine whether they're okay with it.

[rootThatBox]

Hi @TimmyBugcrowd and @nightpool,
I see the points mentioned, however, I am not sure if we should consider modern security controls or CSP here as it's technically out of scope (similar to considering WAF )

Also, If we are looking at the direct impact of HTML injection
then we can consider

• Data exfiltration through CSS injection (ref https://portswigger.net/research/blind-css-exfiltration )
• Stealing user's IP address through IMG tag
• Front-end DoS by creating an HTML Popup
  If a researcher is creative there can be more application-specific impact through HTML Injection (that is more than the severity of P5)

I think
A good solution here is There can be two variants
Limited HTML Content Injection -> P5 (in which the researcher isn't able to load images, or use multiple HTML tags to create a good exploit and the injection is restricted )

HTML Content Injection -> P4 (in which the researcher is not restricted and can use different tags and attributes etc to create a good impact )

Please let me know what you think.
Thanks

[TimmyBugcrowd]

Thanks for your replies. We will discuss this in our next meeting with the team and let you know here what the rest of the team thinks about this.

[TimmyBugcrowd]

Hi @rootThatBox

We've decided to keep it as P5 since the impact is mostly cosmetic or context-dependent. Higher-impact cases can be escalated case-by-case.