标签：#SEC

Instead of immediately opening pull requests when newer dependency versions are released, Dependabot now waits three days before suggesting upgrades, thus increasing the likelihood that malicious releases are identified and removed before they can be integrated. By Sergio De Simone

TL;DR AI editors add a login check to your API routes but skip the ownership check, so any logged-in user can read another user's data by changing the ID in the URL (CWE-639, IDOR). It happens because tutorials treat "authenticated" as if it means "authorized," and the AI learned from those tutorials. The fix is one line: scope every lookup to the current user instead of trusting a raw ID from the request. I asked Cursor to build an endpoint that returns an invoice by ID. It gave me clean code. Auth middleware on the route, a database lookup, a JSON response. It ran on the first try. Then I logged in as a different test user and changed the number at the end of the URL. Invoice #1001 belonged to someone else. I got the whole thing back: amount, line items, billing address. No error, no warning. Just another user's private data on my screen. That is IDOR, an Insecure Direct Object Reference, and it is one of the most common holes I find in AI-generated APIs. The frustrating part is that the code looks secure. It even has an auth check. It just checks the wrong thing. The Vulnerable Code The endpoint below is broken because it confirms you are logged in but never confirms the invoice is yours. findById takes the ID straight from the URL and returns whatever it finds. // CWE-639: authenticated, but no ownership check app . get ( ' /api/invoices/:id ' , authenticate , async ( req , res ) => { const invoice = await Invoice . findById ( req . params . id ); res . json ( invoice ); }); The authenticate middleware does its job. It proves the request comes from a real, logged-in user. What it does not prove is that this particular user has any right to invoice :id . Change the ID, get someone else's record. Increment it in a loop and you can walk the entire table. Why This Keeps Happening AI editors confuse authentication with authorization because almost every tutorial they trained on does the same thing. Authentication is "who are you." Authorization is "are you allowed to

Explore the changes we've shipped across npm and GitHub Actions over the past few months to disrupt supply chain attack techniques and limit their impact. The post Disrupting supply chain attacks on npm and GitHub Actions appeared first on The GitHub Blog .

As a site reliability engineer in a global company, I'm running a modern (well, relatively modern, to be honest and modest) cloud-native stack: HashiCorp Vault as the secret manager, workloads on Kubernetes clusters in AWS (EKS), and development workflows automated through Jenkins (legacy) and GitLab CI. This setup is, quite likely, familiar to you — it's the normal playbook in the cloud-native era. In theory, we have the right tools for both security and efficiency: After all, we have a state-of-the-art secret manager integrated with everything. But in reality, it's far from the truth. See if you resonate with the following scenarios: Scenario A: A new colleague just joined the team. Manager: "Your initial password to log in to your corporate account came to me via email, but since you can't log in to your mail account just yet, here, take a picture of my screen." (In some companies, taking a picture of a computer monitor would get you fired, I'm not kidding.) Scenario B: A developer needs a temp password to access a database. Dev: "Where is the newly created temporary password? Need it for debugging." Ops: "In the Vault." Dev: "I can't access Vault." Ops: "No, you can't. It's not safe to open UI access to Vault. Corporate policy." Dev: "Then how can I get the password?" Ops: "Well... Technically, the password isn't in the Vault. There is a Jenkins pipeline that calls the Vault API to generate a temp password, then stores it in Jenkins secrets. You need to request access to the corresponding Jenkins pipeline, trigger it, then get the secrets from Jenkins." Dev: "Why on earth do we store secrets in Jenkins when we have Vault, which we aren't allowed to use?" Ops: "Corporate policy, just told you." Scenario C: A new ops team member needs to update a certificate for a service running in production for the first time. Ops: "Where is the old cert?" Mentor: "In K8s as a secret." Ops: "Where is the cluster?" Mentor: "In AWS." Ops: "How do I access that?" Mentor: "You need

I read a post this week where someone connected three MCP servers to one agent and watched it casually request the same access it'd need to hit production. The comment thread was full of "yeah, that's the whole problem with MCP" takes, and I almost scrolled past it — I don't run three servers, I run one. Then I actually opened server.py to check, and realized my one server has the exact same shape of problem, just folded into a single file instead of spread across three. server.py is a FastMCP server with 8 tools split across two unrelated jobs: GitHub profile/repo reads, and DEV.to article reads and writes. Both credentials get loaded the same way, at import time, into the same process environment: def load_env ( path = " .env " ): try : with open ( path ) as f : for line in f : line = line . strip () if line and not line . startswith ( " # " ) and " = " in line : k , v = line . split ( " = " , 1 ) os . environ . setdefault ( k , v ) except FileNotFoundError : pass load_env () and two helper functions read them back out: def _gh ( path , method = " GET " , data = None ): req = urllib . request . Request ( f " https://api.github.com { path } " , method = method ) req . add_header ( " Authorization " , f " token { os . environ [ ' GITHUB_TOKEN ' ] } " ) ... def _dev ( path , method = " GET " , data = None ): req = urllib . request . Request ( f " https://dev.to/api { path } " , method = method ) req . add_header ( " api-key " , os . environ [ " DEV_TO_API " ]) ... Nothing here is a bug in the sense of "wrong output for some input." Every tool does exactly what it says: get_github_profile reads GitHub, create_article writes to DEV.to. The problem is one level up, in what the process boundary actually protects. I'd been thinking of GITHUB_TOKEN and DEV_TO_API as belonging to different tools , scoped by which function reads them. They don't. They belong to the process . Every one of those 8 tools runs with both credentials sitting in its environment, whether the tool ne

AWS released a public preview of the GuardDuty investigation agent, which correlates findings, 90-day activity logs, and resource topologies into structured reports with risk ratings, confidence scores, and MITRE ATT&CK classification. It is reachable through the AWS MCP Server, so investigations can run from agentic tooling. Preview quotas cap usage at 10 investigations per account per day. By Steef-Jan Wiggers

Researchers tested top image editing models on Hugging Face and found they could easily create explicit deepfakes—and 1,000 image editing prompts show how people use the software.

One word broke into a private repository this month. Not a zero-day. Not stolen credentials. Not...

The flow will be: Authentication foundation Session vs JWT JWT deep dive JWT security Access/Refresh tokens OAuth2 relationship with JWT End-to-end production flow PKCE Storage strategies summary 1. Authentication Fundamentals Every secure application needs answers to two questions: Authentication "Who are you?" Example: User enters: username password MFA System verifies identity. Result: User is Bhargav Authorization "What are you allowed to do?" Example: User: Bhargav Permissions: READ_ORDERS CREATE_ORDER DELETE_ORDER Authentication happens first. Authorization happens after. Authentication | v Authorization 2. Traditional Session-Based Authentication (Stateful) Before JWT, applications commonly used sessions. Flow User logs in: Browser | | username/password | v Server Server creates: Session ID = abc123 Stores: Database / Memory abc123 | | User: Bhargav Role: ADMIN Browser receives: Cookie: SESSION_ID=abc123 Every Request Browser sends: GET /orders Cookie: SESSION_ID=abc123 Server: Receive Session ID | v Search session storage | v Find user | v Allow request Problems with Sessions 1. Server maintains state The server must remember: Session ID | v User Information 2. Scaling problem Imagine multiple servers: Load Balancer / \ Server A Server B User logs in: Server A Session stored here Next request: Server B No session found Solutions: Sticky sessions Shared session database 3. JWT Authentication (Stateless) JWT solves this by putting information inside the token. JWT: JSON Web Token It is a compact, signed representation of claims between two parties. Example: eyJhbGciOiJIUzI1Ni... JWT vs Session Session Server stores user state: Server Session ID | v User Data JWT Token contains information: JWT Header + Payload + Signature Server does not need to store session information. 4. JWT Structure A JWT has three parts: HEADER.PAYLOAD.SIGNATURE Example: xxxxx.yyyyy.zzzzz Part 1: Header Contains metadata. Example: { "alg" : "RS256" , "typ" : "JWT" } Meaning: JWT uses RS

Dysphoria: A 200k-Device Botnet Using Blockchain Name Resolution and Infected Device Relays 1. Basic Information Article Title : New Dysphoria DDoS botnet spreads to 200k devices worldwide Publisher : BleepingComputer Publication Date : 2026-07-27 Original Source : https://www.bleepingcomputer.com/news/security/new-dysphoria-ddos-botnet-spreads-to-200k-devices-worldwide/ Primary Source : https://blog.xlab.qianxin.com/dysphoria/ Related Entities : Dysphoria, jackskid, fbot, ENS, SNS, UPnP, Telnet, SSH, IoT/embedded Linux Related CVEs : CVE-2013-3307, CVE-2016-20016, CVE-2017-17215, CVE-2017-5259, CVE-2018-14558, CVE-2020-25499, CVE-2020-8515, CVE-2022-35733, CVE-2025-9528, CVE-2025-28137, CVE-2025-34152, CVE-2025-55182, and others Severity : High Main IOCs : burrberry.eth , ukranianhorseriding.eth , 24carnforth2merseyside.sol , login.trees4sale.net , c2.saintpetersburgresident.ru 2. Summary This is a large-scale Linux botnet. It breaks into devices using weak Telnet/SSH passwords and various IoT RCE vulnerabilities. It gets multi-stage C2 servers from ENS/SNS records. It turns infected devices into relay nodes or DDoS bots by opening 155 ports using UPnP. 3. Attack Flow Infection and DDoS Chain Attackers compromise routers, gateways, and cameras using weak Telnet/SSH credentials or known RCE vulnerabilities. The malware runs a Linux binary. It hides its process name as libdalvikengine.so . It decrypts strings using modified RC4 (with added LCG/LFSR). It reads TXT and custom records from ENS/SNS, converts fake IPv6 formats, and gets distributor node IP addresses. It gets a list of infected device relays from http://<node>:9000/nodes?key=meowmeowmeow . It connects to the C2 server using a fixed 78-byte login and heartbeat. It executes DDoS commands that include duration, attack type, target, and flag. Relay-Only Chain A relay variant without DDoS features searches for UPnP-enabled gateways. It creates 155 port forwards on the WAN side and listens on its own device. It

Public Wi‑Fi DNS Poisoning: Hijacking Microsoft 365 Sessions of Business Travelers 1. Basic Information Article Title : Hacked Public Wi-Fi Gateways Used to Harvest Corporate Credentials Source : SecurityWeek Publication Date : 2026-07-27 Original Article : https://www.securityweek.com/hacked-public-wi-fi-gateways-used-to-harvest-corporate-credentials/ Primary Source : https://reliaquest.com/blog/threat-spotlight-dns-poisoning-tactics-expand-to-hospitality/ Related Entities : Microsoft 365, Entra ID device-code flow, DNS poisoning, AiTM, WPAD, captive portal, FrostArmada, APT28 (attribution unconfirmed) Severity : High IOCs : 38.146.28.75 , 31.57.243.154 , 104.194.159.150 , m365-owa.com , owa-ms365.com , ms365-device.com , ms365-live.com 2. Executive Summary This attack compromises Wi-Fi gateways at locations like hotels to forge DNS responses. It does not send phishing emails. Instead, it tricks users into visiting fake Microsoft pages, using WPAD proxies, and entering device-code authentication. This allows attackers to steal MFA-authenticated Microsoft 365 sessions. 3. Attack Flow Chain A: DNS Redirection and Credential Theft Attackers gain administrative access to captive portal gateways in hotels or conference centers. Hypothesis (Primary source confidence: Low to Medium) : Public SSH/SNMP/Web management interfaces and weak, reused administrator credentials are used for initial access. The gateway returns fake responses for DHCP-assigned DNS or passing DNS, resolving normal domains to attacker IPs. Users are redirected to fake Microsoft pages to collect credentials and OAuth information. Attackers log into Microsoft 365 using the stolen credentials and tokens. Chain B: WPAD The gateway controls wpad name resolution or DHCP option 252. The device downloads the attacker's PAC file. Windows app and browser traffic pass through the attacker's proxy. Investigations observed attempts, but successful execution is unconfirmed. Chain C: Device-Code Flow The fake page sh

FortiOS CVE-2025-68686: Bypass of Symlink Persistence Mitigation for Already Compromised Devices 1. Basic Information Article Name : CISA Adds Two Known Exploited Vulnerabilities to Catalog Source : CISA Publication Date : July 27, 2026 Original Link : https://www.cisa.gov/news-events/alerts/2026/07/27/cisa-adds-two-known-exploited-vulnerabilities-catalog Related Sources : https://fortiguard.fortinet.com/psirt/FG-IR-25-934 https://nvd.nist.gov/vuln/detail/CVE-2025-68686 Related Entities : CVE-2025-68686, FortiOS, SSL-VPN, symlink persistence, CISA KEV Severity : Critical 2. Summary This is an actively exploited vulnerability. An attacker who has already compromised the FortiOS file system via another vulnerability can use a crafted HTTP request to bypass symlink persistence mitigations. This allows access to sensitive files through the SSL-VPN web interface even after an upgrade. 3. Attack Flow An attacker compromises FortiOS down to the file system level using another vulnerability or path. The attacker places a symlink pointing to out-of-bounds system files into the SSL-VPN related area. An administrator applies standard patches or firmware updates, but the malicious symlink or its recreation path remains. The attacker bypasses the mitigation using a crafted HTTP request via CVE-2025-68686. The attacker may read sensitive files such as configurations, credentials, and keys from the SSL-VPN web interface. The attacker may use the stolen information to continue VPN authentication, administrative access, and internal intrusion. 4. Attacker Position and Execution Location Initial compromise and symlink placement happen on the FortiGate/FortiOS device. Mitigation bypass and file reading occur externally via the SSL-VPN HTTP(S) interface. This CVE alone does not provide initial file system access to uncompromised devices. 5. Visibility for Victims and Administrators The device may look updated, but unauthorized symlinks can remain. Crafted HTTP requests to the SSL-VPN w

Certighost CVE-2026-54121: Low-Privilege Users Impersonate a DC via AD CS 1. Basic Information Article Title : New Certighost PoC exploit lets attackers hijack Windows domains Source : BleepingComputer Published Date : 2026-07-27 Original Article : https://www.bleepingcomputer.com/news/security/new-certighost-poc-exploit-lets-attackers-hijack-windows-domains/ Primary Source : https://gist.github.com/H0j3n/a5ef2609b5f2944ac2390a191a534c26 Related Entities : CVE-2026-54121, Certighost, Microsoft AD CS, Enterprise CA, PKINIT, Kerberos, DCSync, Impacket Severity : High 2. One-Sentence Summary A public PoC allows a low-privilege domain user to point AD CS "chase" references to an attacker host, trick the CA into trusting fake LDAP/LSA responses to get a Domain Controller certificate, and then take over the entire domain using PKINIT and DCSync. 3. Attack Flow An attacker connects to LDAP with a low-privilege domain account and lists CAs, DCs, and Domain SIDs/GUIDs. The attacker uses the default ms-DS-MachineAccountQuota=10 setting to create a computer account and register an SPN. The attacker starts fake LDAP and LSA services on their host. The attacker specifies their host in the certificate request's cdc (Client DC) field and the target DC in the rmd (Remote Domain) field. The CA connects to the attacker-specified cdc via SMB/LDAP to chase the reference. The attacker's service relays the CA's authentication challenge to the real DC and returns the target DC's objectSid and dNSHostName . The vulnerable CA treats the returned data as authoritative and issues a certificate containing the target DC's SID and DNS name. The attacker uses PKINIT to get a Kerberos TGT as the DC and saves it to a .ccache file. The attacker performs a DCSync using the DC account's replication rights to steal secrets, including krbtgt . 4. Attacker Position and Execution Location The attacker needs a host inside the domain with valid authentication that can reach the CA, DC, and SMB/LDAP ports. T

MedusaHVNC: Remote Control of Logged-in Browsers on Hidden Windows Desktops 1. Basic Information Article Title : MedusaHVNC Malware Uses Hidden Windows Desktops to Evade Detection Publisher : SecurityWeek Publication Date : 2026-07-27 Original Article : https://www.securityweek.com/medusahvnc-malware-uses-hidden-windows-desktops-to-evade-detection/ Primary Source : https://www.blackfog.com/medusahvnc-a-hidden-desktop/ Related Entities : MedusaHVNC, MaaS, HVNC, JScript, AutoIt, charmap.exe , ChaCha20, Chrome/Edge/Firefox Severity : High IOCs : 51.89.204.28:4444 , %TEMP%\Nx2981Okkr2\ , AFLlvOscPj.bat , zorsxklxfehdoals 2. Executive Summary This is a RAT that uses JScript, AutoIt, charmap.exe injection, and multi-layer decryption to open logged-in browsers on a hidden Windows desktop invisible to the user. It controls existing cookies and sessions using the victim device's original IP address. 3. Attack Flow wscript.exe runs an obfuscated JScript file and waits for 7,584 milliseconds. It extracts the AutoIt execution system, configuration, and encrypted payload to %TEMP%\Nx2981Okkr2\ . It places AFLlvOscPj.bat in the Startup folder for persistence. AutoIt decrypts the payload using single-byte XOR 0xAE . It starts the legitimate C:\Windows\System32\charmap.exe and injects the loader into it. It decrypts the final x64 PE file using 16-byte repeating XOR and ChaCha20. It makes a custom TCP connection to 51.89.204.28:4444 . It creates another hidden desktop and launches Chrome, Edge, or Firefox. It captures screens using BitBlt and PrintWindow , sends inputs using SendInput , and moves data using the Clipboard API. It uses cookies and sessions from existing browser profiles to control user accounts. 4. Attacker Position and Execution Location The attacker uses a MaaS operation panel and C2 server. The loader and HVNC run on the Windows device, and the browser runs on a separate desktop invisible to the user, but on the same device, IP, and profile. The initial delivery ve

VeloCloud Orchestrator CVE-2026-16812: Unauthenticated OS Command Injection Actively Exploited 1. Basic Information Article Title : Arista patches VeloCloud Orchestrator zero-day exploited in attacks Source : BleepingComputer (Primary Source: Arista Security Advisory 0144) Publication Date : 2026-07-27 Original URL : https://www.bleepingcomputer.com/news/security/arista-patches-velocloud-orchestrator-zero-day-exploited-in-attacks/ Related Sources : https://www.arista.com/en/support/advisories-notices/security-advisory/24364-security-advisory-0144 https://www.cisa.gov/news-events/alerts/2026/07/27/cisa-adds-two-known-exploited-vulnerabilities-catalog Related Entities : CVE-2026-16812, CWE-78, VeloCloud Orchestrator (VCO) On-Premises, VeloCloud Edge, CISA KEV Severity : Critical IOCs : 8.19.75.217 , 206.72.242.124 , 206.72.242.162 2. Summary This is a CVSS 10.0 vulnerability. It allows an unauthenticated attacker to access the Web UI of an internet-reachable on-premises VCO. The attacker can execute OS commands through internal-only functions. Active exploitation has been confirmed. 3. Attack Flow An attacker searches for a VCO Web interface. The attacker sends a crafted request without authentication to reach internal-only functions. The attacker executes commands on the VCO host via OS command injection. The attacker may access configurations, device lists, credentials, certificates, keys, and databases. The attacker proceeds to create files, export databases, create archives, perform outbound communications, and change management configurations. Inference : The attacker can abuse the authentication and configuration paths to Edge devices managed by the VCO, expanding the impact to the entire SD-WAN. 4. Attacker Position and Execution Location The attacker is an external host with network access to the VCO Web UI. The initial request targets the web layer. Commands execute on the on-premises VCO host. Hosted and Dedicated VCOs are already patched. VeloCloud Gateways

Microsoft says tools cost less than competing ones and outperform them, too.

JWT authentication has more failure modes than most developers realise. Correct signature verification is necessary but far from sufficient. This checklist is what I run through before every production JWT deployment. 1. Secret Is Generated With a CSPRNG Not a password. Not a UUID. Not a timestamp. A cryptographically secure pseudorandom number generator output. In Node.js: crypto.randomBytes(32).toString('hex') In Python: secrets.token_hex(32) In the browser: jwtsecretgenerator.com/tools/jwt-secret-generator A 256-bit CSPRNG secret takes 10^59 years to brute force at current GPU speeds. 2. Algorithm Is Explicitly Specified in verify() // Wrong jwt . verify ( token , secret ); // Right jwt . verify ( token , secret , { algorithms : [ ' HS256 ' ] }); 3. exp Claim Is Present and Validated Short-lived tokens (15 minutes) limit the damage from leaks. Verify your library is actually checking exp — some require explicit configuration. 4. iss and aud Claims Are Validated Validates the token was issued by your service and intended for your API. Prevents token reuse across services. 5. Tokens Are in httpOnly Cookies, Not localStorage localStorage is readable by any script on the page. httpOnly cookies are invisible to JavaScript. 6. HTTPS Is Enforced JWT in a query parameter over HTTP is visible in every proxy, CDN, and server log on the path. Use the Authorization: Bearer header over HTTPS only. 7. Refresh Tokens Are Server-Side Revocable Short access tokens + server-side refresh tokens = the ability to end sessions immediately. Long-lived access tokens without refresh logic cannot be revoked. 8. The jti Claim Is Used If You Need Immediate Revocation Store revoked jti values in Redis with TTL matching token expiry. Check on every request. Adds one Redis lookup per request — worth it for high-security endpoints. 9. Different Secrets for Each Environment Dev secret leaks should not compromise production. Keep them separate. 10. Secret Is Not in Source Code or Version Control

The outgoing executive director of the Office of Homeland Security Statistics is one of very few federal officials to speak out against the Trump administration’s immigration crackdown.

The screwup shows how tricky it can be to stop web crawlers from making ostensibly private conversations with AI chatbots entirely too public.

Everything you need to know to find your first vulnerability, get paid, and build a real reputation in cybersecurity — without breaking any laws. If you've typed "how to start bug bounty hunting" into Google recently, you're not alone. It's one of the fastest-growing searches in cybersecurity right now, and for good reason: it's one of the only paths in tech where a total beginner with no degree can find a real flaw, report it, and get paid the same week. This guide answers the questions people are actually searching in 2026 — what bug bounty hunting is, which bugs pay the most right now, how AI has changed the game, and how to land your first bounty. What Is Bug Bounty Hunting, Exactly? Companies invite independent researchers to test their websites, apps, and APIs for security flaws — legally. When you find a real vulnerability, you write a report explaining what it is, how to reproduce it, and what damage it could cause. If the company confirms it, they pay you based on severity. It's not hacking in the movie sense. It's structured, permitted testing within a defined scope — the specific domains, apps, or features the company has authorized you to test. Step outside that scope, and you've crossed from "bug bounty hunter" into "unauthorized access," which is a crime in nearly every country. The Best Platforms to Start On in 2026 Three platforms dominate the space: HackerOne — the largest and most beginner-friendly, with the widest range of programs Bugcrowd — strong onboarding and clear scope documentation Immunefi — the go-to platform if you're interested in web3 and smart contract security, which currently pays some of the highest bounties in the industry Start with Vulnerability Disclosure Programs (VDPs) — these often don't pay, but they let you build a track record, earn private invites, and practice on real targets without competing against thousands of other hunters for a bounty. What Bugs Are Actually Paying Right Now The vulnerability landscape has shifte