I’m conducting authorized testing for a HackerOne bug bounty program and I’m encountering an Akamai access-control/WAF block on several explicitly in-scope assets:

• www.meesho.com
• prod.meeshoapi.com
• supplier.meesho.com
• admin.meeshosupply.com

Interestingly, affiliate.meesho.com, which is also in scope, is reachable from the exact same testing environment.

Current diagnostics

I’m running Kali Linux in a VM.

So far:

• DNS resolution: working
• TCP/443 connectivity: working
• TLS 1.3 handshake: working
• HTTP requests: consistently return 403 Access Denied
• Response is served by Akamai
• Akamai Bot Manager cookies such as bm_* are returned
• The required HackerOne identification header is present: X-Hackerone: xplorertech00

For example:

curl -sS -D /tmp/meesho.headers \
  -o /tmp/meesho.body \
  -H 'X-Hackerone: xplorertech00' \
  https://prod.meeshoapi.com/

This consistently results in an HTTP/2 403 response from Akamai. The other affected hosts behave similarly.

I’ve already ruled out basic DNS, routing, TCP, and TLS problems. The denial appears to be occurring at the HTTP/Akamai layer.

I’m not trying to bypass the WAF. I want to remain fully within the bug bounty rules and find the correct, authorized way to perform testing when an in-scope target is unreachable from the current testing network.

Options I’m considering

• Test from another legitimate ISP/network that I control.
• Ask the program to allowlist my testing IP.
• Ask whether the program provides an approved testing egress, VPN, or testing environment.

Questions for other researchers

1. If an Akamai reputation/access-control block is responsible, does switching to another legitimate ISP/network generally resolve the issue?
2. Is there a standard workflow researchers use with HackerOne programs when an in-scope asset is inaccessible due to CDN/WAF restrictions?
3. Would you recommend contacting the program first to request IP allowlisting rather than repeatedly switching networks?
4. What diagnostic information should I collect before contacting the program so they can determine whether the block is intentional or an accidental restriction?

I’d especially appreciate advice from researchers who have dealt with Akamai restrictions during authorized bug bounty testing.

Hello everyone,

I want the best open weight local model for my hardware, primarily for cyber security and coding.

My computer
GPU: NVIDIA RTX 3050 Laptop GPU
VRAM: 6 GB OS: Windows 11 + WSL2
WSL: Ubuntu 24.04.4 LTS llama.cpp: compiled from source with CUDA 13.3
Inference: GGUF/llama.cpp
If the model is worth it I can offload the CPU/RAM.
What I want to

I am looking for the best trade-off between:

Cybersecurity knowledge - Vulnerability analysis, CTFs, pentesting, security tooling, malware/code analysis, defensive security, etc.
Coding skills Python
Reasoning — I care much less about the number of parameters than the actual ability to solve problems.
Legitimate cybersecurity research and lab / ctf use, low refusal / less restrictive behavior is desired.

Right now I am looking at models like:

RedSage 8B Qwen3.5-9B Qwen3-14B
Qwen3-Coder models
WhiteRabbitNeo, Qwythos-9B-Claude-Mythos

But I am struggling to decide if a high quality 8-9B model that fits better on 6GB is better than a larger MoE/14B model with heavy CPU offloading.

My primary question

What model + GGUF quantization would you recommend for this hardware if the focus is cybersecurity + coding not general chat?

I’m really looking for recommendations based on actual cybersecurity / coding benchmarks or real-world experience, not just parameter count.

also interested in recommended llama.cpp settings (-ngl, context size, KV cache quantization, CPU/GPU offloading, etc) for 6GB vram.

Thanks.