u/allexj

I'm currently dealing with an incredibly frustrating situation on YesWeHack and looking for advice, as the platform's mediation team has completely ghosted me.

Situation: I submitted a Critical vulnerability (Global Account Takeover via Insecure TLS Validation) 6 months ago. The vendor accepted it at CVSS 9.6 (Critical). However, they only paid me out for the "High" tier (shortchanging the "Critical" tier by nearly 60%). Furthermore, they explicitly promised me in writing that I would be credited on the CVE. Fast forward: a CVE is published for this exact issue/component, but credited to a notable and famous third party. The vendor ghosted me.

CVSS Manipulation: 1.5 months ago, I finally got YesWeHack support to poke the vendor. The vendor's response? They retroactively downgraded my CVSS from 9.6 to 8.2 (changing an automated Wi-Fi MitM from Adjacent/Low Complexity to Local/High Complexity) solely to justify their underpayment.

Ghosting: I escalated this clear CVSS manipulation and matrix abuse to YesWeHack Support on July 7th. No reply. I sent a harsh follow-up on August 8th. Still absolutely no reply. It's August 20th.

On top of this, the same vendor closed another 9.9 architectural E2EE flaw as "Won't Fix" (a silent security downgrade where the app drops E2EE and uploads plaintext media to their cloud without user warning) just to avoid another payout.

Is it normal for YWH to let vendors retroactively manipulate vectors to dodge payouts and then ghost researchers who ask for mediation? Who can I contact to escalate this past the Tier 1 support desk?

Hi everyone,

I need advice on how to get YesWeHack staff to intervene or review a ticket, as I don't see a "Request Mediation" button on the report interface.

The Situation:

• My Report: I submitted a Critical bug (CVSS 9.6) regarding an iOS/Android app. The vendor accepted it, paid a bounty (though underpaid by ~60% based on their own matrix), and explicitly wrote: "We will apply for a CVE on your behalf and list your name as the reporter." After the payout, they completely ghosted my follow-up messages.
• The Suspicion: A few days ago, a public CVE dropped for the exact same app. The CVE was "Reserved" just 3 days before the vendor promised me the credits in writing.
• The Dilemma: The public CVE credits Cisco Talos and the technical description is different from what I reported (it talks about unencrypted legacy APIs, whereas I reported a TLS chain validation flaw). However, given the identical timeline and app, I strongly suspect they might be related, or affecting the same component.

Since the vendor is ignoring my comments, I want YesWeHack to step in so I can get clear answers on whether this CVE is connected to my findings, and why the payout matrix wasn't respected.

My Question:

What is the best way to open a support ticket or call for mediation with YesWeHack staff when a vendor ghosts you? Has anyone experienced something similar?

Thanks!

Take a look, for example, at the section "3 ways AI hallucinations are impacting cybersecurity": https://thehackernews.com/2026/05/how-ai-hallucinations-are-creating-real.html?m=1#3-ways-ai-hallucinations-are-impacting-cybersecurity

It feels verbose without saying much of value.

Using reliable services that usually (I know they are not perfect) get detection right, such as "gptzero.me", it turns out that it was indeed written by AI.

Where will we end up if even articles discussing the risks of AI are written by AI?

We need to introduce some regulations and require that a specific pattern or signature be included in some way within the text, images or videos generated, so that we can determine whether or not the content is of human origin. Is there a study or discussion underway somewhere in a law firm or research centre looking into this?

I have a technical question about how Microsoft Defender for Endpoint (MDE) and Windows Sandbox interact at the network level.

The scenario: Host PC with MDE and Network Protection enabled. Host alerts are regularly forwarded to a SIEM/SOAR. I open Windows Sandbox on the host PC and, from inside the isolated environment, I try to browse a known malicious site (e.g., phishing or C2).

The question: Considering I'm using the Sandbox, does the host's Network Protection still manage to intercept the request, block it, and trigger the alert to the SIEM? Or does the Sandbox isolation "hide" the traffic from the host's Defender, preventing the alert from triggering?

I have a technical question about how Microsoft Defender for Endpoint (MDE) and Windows Sandbox interact at the network level.

The scenario: Host PC with MDE and Network Protection enabled. Host alerts are regularly forwarded to a SIEM/SOAR. I open Windows Sandbox on the host PC and, from inside the isolated environment, I try to browse a known malicious site (e.g., phishing or C2).

The question: Considering I'm using the Sandbox, does the host's Network Protection still manage to intercept the request, block it, and trigger the alert to the SIEM? Or does the Sandbox isolation "hide" the traffic from the host's Defender, preventing the alert from triggering?

I have a technical question about how Microsoft Defender for Endpoint (MDE) and Windows Sandbox interact at the network level.

The scenario: Host PC with MDE and Network Protection enabled. Host alerts are regularly forwarded to a SIEM/SOAR. I open Windows Sandbox on the host PC and, from inside the isolated environment, I try to browse a known malicious site (e.g., phishing or C2).

The question: Considering I'm using the Sandbox, does the host's Network Protection still manage to intercept the request, block it, and trigger the alert to the SIEM? Or does the Sandbox isolation "hide" the traffic from the host's Defender, preventing the alert from triggering?

Hi everyone, I'm reviewing a "Critical - Ransomware" alert ("VSS Shadow Copies Deletion Attempt detected") and I have a question about the timestamps and mitigation logic.

Here is the timeline from the report:

• 06:28:24 - vssadmin.exe executes delete shadows /for=C: /oldest
• 06:30:28 - diskshadow.exe is executed (presumably a fallback)
• 06:31:06 - SentinelOne executes "Kill" (11/11 processes) and "Quarantine". Mitigation status is "Success / Mitigated".

The dilemma: There is a 3-minute gap between the first execution and the final Kill action.

Does the SentinelOne agent intercept and block the deletion command at the kernel level in real-time (06:28), or is there a risk the shadow copies were actually purged before the Kill at 06:31?

SentinelOne, in the alert, consistently uses the word "attempted", which implies the deletion failed... but is Sentinel just being optimistic, or can I trust that "attempted" means the backups are 100% safe despite the delayed Kill?

Hi everyone, I'm reviewing a "Critical - Ransomware" alert ("VSS Shadow Copies Deletion Attempt detected") and I have a question about the timestamps and mitigation logic.

Here is the timeline from the report:

• 06:28:24 - vssadmin.exe executes delete shadows /for=C: /oldest
• 06:30:28 - diskshadow.exe is executed (presumably a fallback)
• 06:31:06 - SentinelOne executes "Kill" (11/11 processes) and "Quarantine". Mitigation status is "Success / Mitigated".

The dilemma: There is a 3-minute gap between the first execution and the final Kill action.

Does the SentinelOne agent intercept and block the deletion command at the kernel level in real-time (06:28), or is there a risk the shadow copies were actually purged before the Kill at 06:31?

SentinelOne, in the alert, consistently uses the word "attempted", which implies the deletion failed... but is Sentinel just being optimistic, or can I trust that "attempted" means the backups are 100% safe despite the delayed Kill?

Hi everyone, I'm reviewing a "Critical - Ransomware" alert ("VSS Shadow Copies Deletion Attempt detected") and I have a question about the timestamps and mitigation logic.

Here is the timeline from the report:

• 06:28:24 - vssadmin.exe executes delete shadows /for=C: /oldest
• 06:30:28 - diskshadow.exe is executed (presumably a fallback)
• 06:31:06 - SentinelOne executes "Kill" (11/11 processes) and "Quarantine". Mitigation status is "Success / Mitigated".

The dilemma: There is a 3-minute gap between the first execution and the final Kill action.

Does the SentinelOne agent intercept and block the deletion command at the kernel level in real-time (06:28), or is there a risk the shadow copies were actually purged before the Kill at 06:31?

SentinelOne, in the alert, consistently uses the word "attempted", which implies the deletion failed... but is Sentinel just being optimistic, or can I trust that "attempted" means the backups are 100% safe despite the delayed Kill?

Please if there is a way, tell me