IDOR Vulnerability: Real Examples, How Testers Find It and How to Fix It

An insecure direct object reference (IDOR) vulnerability lets a signed-in user read, change or delete another user's data by altering an identifier in a request, because the server fetches the object without checking that the caller is entitled to it. CISA, the NSA and the Australian Cyber Security Centre devoted a joint advisory to the class in July 2023, warning that these flaws "are frequently exploited by malicious actors in data breach incidents because they are common, hard to prevent outside the development process, and can be abused at scale." In Stingrai's own State of Penetration Testing 2026 dataset, IDOR accounts for 7.9% of all web application findings.

Quick answer. An IDOR vulnerability is a missing ownership check. The application takes an ID from the URL, body, header or cookie, looks the object up, and returns it to whoever asked. It is found by testing with several accounts and replaying one account's requests as another, and it is fixed by enforcing, on the server, that every object a request touches belongs to the caller or to the caller's tenant. Unpredictable IDs make guessing harder but do not replace that check.

This guide is written for developers, security leads and anyone buying a web application or API penetration test. It explains the flaw, walks through six cases documented by regulators, CVE records and the affected vendors, describes how a tester checks for it (the method, not an attack recipe), and ends with fixes and a scoping checklist.

What is an IDOR vulnerability

Every multi-user application hands out references to the things it stores: an order number in a URL, a document ID in a JSON body, a file name in a download link. An IDOR vulnerability exists when the server treats that reference as proof of permission. The OWASP IDOR Prevention Cheat Sheet reduces it to three ingredients:

• An object, such as an account, document, support ticket, transaction or partner profile.

• A reference to that object, in the form of an ID, UUID, account number, token or slug.

• A missing object-level authorization check, which lets a user reach an object they should not be able to reach.

In a server log, the flaw looks unremarkable. Two requests from the same session, both well formed, both answered:

1GET /api/invoices/1042   session: user A (owns invoice 1042)    200 OK
2GET /api/invoices/1043   session: user A (invoice 1043 is B's)  200 OK   <- should be 403 or 404

Nothing was injected and nothing crashed. The second response is a vulnerability only because invoice 1043 belongs to someone else, and that fact lives in the application's business rules, not in the HTTP exchange.

IDOR, BOLA and broken access control: one flaw, several names

The vocabulary causes more confusion than the bug does. These terms overlap as follows.

The joint CISA advisory splits IDOR into four types. Horizontal IDOR is access to data at the same privilege level, such as another customer's record. Vertical IDOR is access to data that needs a higher privilege level. Object-level IDOR is the ability to modify or delete an object, and function-level IDOR is access to a function or action the user should not have. OWASP's API list files that last one separately as broken function level authorization. A companion post covers how BOLA relates to BFLA and mass assignment, so this guide stays with the object reference itself.

Where the reference hides

The identifier is rarely as obvious as a number at the end of a URL. OWASP notes that object IDs "can be anything from sequential integers, UUIDs, or generic strings" and can sit in the path, the query string, request headers or the request payload. CISA's advisory names four places where tampering happens: form fields in a POST body, identifiers in URLs, IDs stored in cookies, and values inside JSON requests. In practice the list also includes file names in download and export links, parent and child IDs in nested routes, GraphQL variables and node IDs (see our GraphQL vulnerabilities guide), and the API calls a mobile app makes once its traffic is readable, which is why our SSL pinning bypass write-up ends with IDOR findings.

Why IDOR ranks so high and still gets missed

Broken access control holds first place in the OWASP Top 10:2025, and OWASP reports that "100% of the applications tested were found to have some form of broken access control." Its list of common failures includes "Permitting viewing or editing someone else's account by providing its unique identifier (insecure direct object references)", and CWE-639 is one of the 40 weaknesses mapped to the category. MITRE's 2025 CWE Top 25 tells the same story from CVE data: CWE-639 entered the list at rank 24, up from 30 the year before, and CWE-862 (Missing Authorization) climbed five places to rank 4.

Stingrai's first-party numbers agree. Across 55 penetration tests and 1,206 verified findings logged between October 2024 and August 2026, 66 findings (5.5%) were IDOR or object-level authorization flaws. In web application testing the share is higher: IDOR is 7.9% of 768 findings, and together with other broken access control it reaches 17.8%. Across all test types, almost a quarter of IDOR findings, 24.2%, were rated Critical.

Figure 1: IDOR among the six largest vulnerability classes in Stingrai's web application test findings. Source: State of Penetration Testing 2026.

Three properties keep the class alive.

The check is absent, not wrong. An injection flaw leaves a pattern in code: user input concatenated into a query. A missing authorization check leaves nothing. The vulnerable handler is shorter and cleaner than the safe one, so it passes code review unless the reviewer knows the ownership rule that should have been there. CISA's advisory makes the same point from the defender's side: each use case "is unique and cannot be mitigated with a simple library or security function."

Scanners have no model of ownership. A scanner sees a valid request and a valid response. The same advisory, while recommending dynamic testing tools, adds a caution: "Not all DAST tools can detect IDOR vulnerabilities." Tools that can may need the environment configured in a specific way and custom rules, and they "are not foolproof and should be used with other security testing methods." The mechanics are covered in why automated API scanners miss BOLA and IDOR.

Many IDORs never get a CVE. They live in bespoke applications and hosted services, so they surface through a breach, a researcher or a penetration test, not a patch bulletin. CISA's Known Exploited Vulnerabilities catalog, at version 2026.11.10 with 1,779 entries, maps exactly one entry to CWE-639. The low count reflects where the flaw lives, not how often it is abused.

Six documented IDOR cases and what each one teaches

Every case below comes from a regulator's order, a CVE record, a government advisory or the affected vendor's own statement. One also draws on the write-up published by the researchers who reported it.

1. First American Financial: found by a penetration test, left unfixed

The clearest account of an IDOR in a regulated business is the SEC's order against First American Financial, announced on 15 June 2021. The company's EaglePro application sent customers links to title and escrow documents. According to the order, "a user could take the URL generated as part of an EaglePro package" and "alter the digits in the URL to view other document images to which the user should not have had access." The repository behind it held approximately 800 million document images, and the defect had been in the application since 2014.

The detail that matters for anyone who buys security testing is in paragraphs 11 to 15. First American's own staff ran a manual penetration test of EaglePro between December 2018 and January 2019. Their report, finalized on 11 January 2019, said that "[r]eplacing the document ID in the web page URL with another sequential number allows access to other non-related document sessions without authentication." It was rated a level 3, "serious" vulnerability with a 45-day remediation window. A clerical error then entered it in the tracking system as level 2, "low risk", with 90 days to fix. It was still open when a journalist reported it to the company on 24 May 2019. Without admitting or denying the findings, First American agreed to pay a $487,616 penalty for disclosure control failures.

Lesson. Finding an IDOR is half the job. The other half is severity that reflects the data behind the object, an owner, a deadline and a retest that proves the fix.

2. A stalkerware backend: one flawed API behind many apps

CERT/CC vulnerability note VU#229438, released on 22 February 2022, describes a backend "shared by multiple mobile device monitoring services" that "does not adequately authenticate or authorize API requests, creating an IDOR (Insecure Direct Object Reference) vulnerability." The CVE record, CVE-2022-0732, lists nine affected products. CISA's advisory cites the incident as a leak of text messages, call records, photos and geolocation from hundreds of thousands of devices. CERT/CC's solution section reads: "We are unaware of a practical solution to this problem."

Lesson. Mobile apps are thin clients for an API, and several apps often share one backend. Authorization has to be tested at the API, and a flaw there belongs to every product in front of it.

3. McHire: an internal API, a forgotten test account and penetration tests that missed it

On 30 June 2025 two researchers, Ian Carroll and Sam Curry, reported a flaw in McHire, the hiring chatbot platform Paradox operates for McDonald's restaurants. Their write-up describes "an insecure direct object reference (IDOR) on an internal API": the request that loaded an applicant's chat took a numeric ID, and changing that number returned another applicant's record. They reached the API through a test account that still accepted a default password, and wrote that the personal data of more than 64 million applicants was within reach.

Paradox's own statement, dated 9 July 2025, confirms "an API endpoint vulnerability" reached through a test account that "had not been logged into since 2019", says the issue was resolved within a few hours, and states that five candidates had information viewed, only by the researchers. Paradox also disputes the scale, saying most of the chat records were not tied to a candidate and held no personal information. It also contains a sentence every security buyer should read twice: "Unfortunately, none of our penetration tests previously identified the issue."

Lesson. A penetration test only covers the roles, tenants and interfaces it is given. Internal and administrative APIs, legacy test tenants and staff-only login paths belong in scope, and the report should say which identities were used against which endpoints.

4. Cisco Slido: a hosted service fixed out of sight

Cisco's advisory for CVE-2026-20219, first published on 6 May 2026 and titled "Cisco Slido Insecure Direct Object Reference Vulnerability", says a flaw in the Slido REST API "could have allowed an authenticated, remote attacker to access the social profile data of other users or affect quiz and poll results." Cisco rated it 5.4 (Medium), mapped it to CWE-639, fixed it in the cloud service with no customer action required, and said it was not aware of malicious use.

Lesson. IDOR is not only a confidentiality problem. The same missing check that lets a user read another user's object usually lets them change it. For hosted software, the customer never sees the patch, so the vendor's testing and disclosure practice is the only assurance available.

5. Langflow: random UUIDs did not help, and the flaw was exploited in the wild

Langflow is a tool for building and deploying AI-powered agents and workflows. Its advisory for CVE-2026-55255, published on 19 June 2026 with a CVSS score of 8.4 (High), describes an IDOR that "allows an authenticated attacker to execute any flow belonging to another user by specifying the victim's flow ID in the request." Versions before 1.9.1 are affected.

The root cause is instructive. One helper function could look a flow up in two ways. When the caller supplied an endpoint name, the query was filtered by the caller's user ID. When the caller supplied a UUID, the advisory says, the function "queries the database directly without verifying if the authenticated user owns that flow." The identifier was long and random, and the flaw was still an IDOR. CISA added the CVE to its Known Exploited Vulnerabilities catalog on 7 July 2026, 18 days after the advisory was published, with a remediation due date of 10 July for US federal agencies.

Lesson. Unguessable IDs are not authorization, because IDs leak through logs, links, exports and other API responses. And every lookup path to the same object needs the same check: by ID, by name, by slug, through a list and through an export.

6. SolarWinds Serv-U: the vertical kind

SolarWinds' advisory for CVE-2026-28317, first published on 21 July 2026, describes "an insecure direct object reference (IDOR) vulnerability that can lead to privilege escalation" in Serv-U 15.5.4 HF1 and earlier. SolarWinds rated it 9.1 (Critical), noted that it "requires domain administrator access" and that the impact is lower in Windows deployments, and fixed it in Serv-U 2026.3.

Lesson. IDOR also runs upward. Here an account that already held administrative rights could escalate further, so tests need to cover privileged roles against each other, not only ordinary users against their peers. Stingrai's own CVE-2026-58433 in Gitea is a close relative: a repository admin could do through one API route what the organization's settings forbade through another.

How a penetration tester checks for IDOR

The OWASP Web Security Testing Guide (test WSTG-ATHZ-04) sets two objectives: identify the points where object references occur, and assess whether the access control around them holds. It also states the requirement that makes this a human-context problem: "The best way to test for direct object references would be by having at least two (often more) users to cover different owned objects and functions." A thorough check follows the same seven steps on every engagement.

1. Agree the access rules first. The tester needs to know what should be denied before they can call something a finding. That means a list of roles, the tenant model, and who may read, change, delete and export each kind of object. Our API authorization test matrix shows the evidence format a buyer can ask for.

2. Provision the identities. At least two accounts per role, in at least two tenants where the product is multi-tenant, plus an administrator and a signed-out session. Each account creates its own objects, so every identifier used in testing belongs to a test account and no real customer data is touched.

3. Inventory every object reference. Using the application as each role while recording traffic, the tester lists each place an identifier appears: paths, query strings, bodies, headers, cookies, file names, GraphQL variables, WebSocket messages and mobile API calls.

4. Replay across identities. Each recorded request is sent again under every other identity and compared with the rule from step 1. The OWASP cheat sheet is explicit that this covers "all operations involving object references, including read, create, update, delete, export, and administrative actions", so a check that holds on a read is tested again on a write.

5. Look where single-record checks are usually forgotten. Export and report endpoints, bulk operations, search and list filters, file downloads, nested routes where the parent ID is checked and the child is not, older API versions, and second lookup paths such as name or slug in place of ID.

6. Test the identifier assumptions. Where IDs are random, the tester looks for places they are disclosed (other responses, shared links, emails, logs visible to lower roles) and confirms that a known ID is still refused.

7. Report with evidence, then retest. Each finding records the identity, the request, the expected result and the actual result, with impact stated in terms of the data or function exposed. After the fix, the same grid is run again.

Figure 2: An illustrative test grid for one object type. Method follows OWASP WSTG-ATHZ-04 and the OWASP IDOR Prevention Cheat Sheet.

The grid explains both the cost and the value of the work. Six operations, five identities and one object type is 30 checks. A product with 20 object types and three API surfaces has 1,800 cells, and the flaw is usually in one of the unglamorous ones. Multi-tenant products add a second axis, covered in our multi-tenant SaaS penetration test scope guide.

Scale is also where purpose-built automation earns its place. Snipe, Stingrai's autonomous AI agent for web applications and associated APIs, tests authenticated across roles and is built to hunt IDOR, broken authorization and business logic flaws, which generic scanners leave alone. In a Hybrid engagement, Stingrai's penetration testers and Snipe test at the same time: the testers direct its focus, extend the paths it opens, and pursue the context-heavy cases, such as a rule that depends on the state of an order or on a relationship between two tenants.

How to fix an IDOR vulnerability

The fix is simple to state and takes discipline to apply everywhere: on every request, for every object, the server confirms that the caller may perform this operation on this object.

Scope the lookup, not the response. The most reliable pattern puts ownership in the query itself, so an object outside the caller's reach is never loaded.

1-- vulnerable: any signed-in caller can load any invoice
2SELECT * FROM invoices WHERE id = :id;
3
4-- fixed: the lookup is bound to the caller's tenant and ownership rule
5SELECT * FROM invoices WHERE id = :id AND tenant_id = :session_tenant AND owner_id = :session_user;

OWASP's cheat sheet shows the same idea in framework terms: look objects up through the current user's own collection, not through the global table. For multi-tenant products, database row level security adds a second layer beneath the application, as our Supabase case study shows.

Take identity from the session, never from the request. If the server can work out whose data is wanted from the authenticated session, the client should not send a user or tenant ID at all. OWASP cautions, though, that comparing the session's user ID with an ID in the request "isn't a sufficient solution" on its own. It handles the simple case and misses objects owned through teams, shares and hierarchies.

Centralize the decision and deny by default. Authorization coded separately in each handler will be forgotten in one of them. Use the framework's policy layer or a dedicated authorization service so that a new route is closed until a rule opens it. OWASP ASVS 5.0 makes the object-level check a Level 1 requirement (8.2.2): data-specific access is "restricted to consumers with explicit permissions to specific data items to mitigate insecure direct object reference (IDOR) and broken object level authorization (BOLA)." Requirement 8.4.1 adds cross-tenant controls for multi-tenant applications.

Treat random identifiers as depth, not as the control. CISA recommends replacing exposed IDs with cryptographically strong random values and, in the same paragraph, notes that "UUIDs and GUIDs should not be used for security capabilities." Langflow is the proof.

Answer the same way for missing and forbidden. Where the existence of an object is itself sensitive, return the same 404 for "does not exist" and "not yours". Langflow's fix does this so that the response cannot be used to confirm which IDs are real.

Put the grid in the build. OWASP's API guidance is blunt: "Write tests to evaluate the vulnerability of the authorization mechanism. Do not deploy changes that make the tests fail." A small set of integration tests that sign in as user B and request user A's objects, for every route, catches the regression that a later feature introduces.

Log and alert on refusals. OWASP's A01 guidance calls for logging access control failures and rate limiting API access, and CISA notes that bursts of 403 and 404 responses are associated with enumeration. One account walking through identifiers should raise an alert long before it reaches the end of the range.

Track every finding to a retest. First American had the finding in hand for more than four months. A fix is done when the test that found it fails to reproduce it.

How to scope IDOR testing in a web application or API penetration test

Whether a test finds IDOR is decided largely before it starts, by what the tester is given. Use this as a checklist when you brief a provider.

• Roles and rules. A written list of every role and what each may do to each object type, including support, partner and internal administrator roles.

• Accounts. Two accounts per role and, for multi-tenant products, two separate tenants. Published packages state their limits: Stingrai's Autonomous Pentest, for example, covers up to three user roles for authenticated testing.

• Every interface to the same data. The web application, the public API, the API behind the mobile app, administrative and internal APIs, older API versions that still respond, and export or reporting services.

• Documentation. An OpenAPI or GraphQL schema where one exists. It shortens the inventory and widens coverage.

• Authenticated, grey-box testing. A black-box test that never signs in can only find the unauthenticated kind of IDOR, and many are behind the login.

• Evidence of what passed. Ask for the identities used and the boundaries exercised, not only the list of findings. OWASP ASVS 5.0 gives you requirement numbers to hold the report against.

• Retesting. Confirm that a retest of fixed findings is included and that its results are written into the final report.

Two questions separate providers quickly: "How many accounts and tenants will you test with?" and "Will the report show which roles were tested against which endpoints?" A provider that tests with one account is not testing for IDOR. Budget and timing guidance is in our web application penetration testing scope and cost guide.

How Stingrai tests for IDOR

Stingrai is a CREST-accredited penetration testing company offering fully human-led and hybrid (human penetration testers plus AI agents) penetration tests, delivered by experienced penetration testers who are also world-class security researchers and bug bounty hunters. The team has 18 published CVEs, and its web application and API penetration tests are authenticated across every user role, covering broken authorization and IDOR, business logic, injection, and authentication and session handling, aligned to the OWASP Top 10 and ASVS and source-assisted where code access is given.

Each human-led engagement is staffed by two named penetration testers from a team holding OSCE³, OSWE, OSEP and CREST CRT certifications. Findings are posted to the PTaaS portal as they are confirmed, each with a working proof of concept and prioritized remediation guidance, and retesting of remediated findings is included. Engagements run as one-time (annual) tests or as continuous programs that test every release.

For one web application and associated APIs, published pricing is fixed. The Autonomous Pentest, run by Snipe, is US$3,000 per assessment or US$650 per month on a 12-month plan. The Hybrid Pentest, where penetration testers and Snipe test together throughout, is US$6,800 per assessment or US$1,275 per month. Larger scopes, including mobile applications and multi-application estates, are quoted per engagement. Details are on the pricing page.

Key recommendations

• Treat every identifier that arrives from a client as untrusted, whether it is a number, a UUID, a file name or a slug.

• Enforce ownership on the server, in the data access layer, for every operation: read, create, update, delete, export and administrative actions.

• Derive the caller's identity and tenant from the session, and deny by default in a central policy layer.

• Use random identifiers as defense in depth and never as the access control.

• Add cross-account authorization tests to the build so a new route cannot ship without a check.

• Log access control failures and alert on enumeration patterns.

• Test with at least two accounts per role and two tenants, across every interface that reaches the same data.

• Rate IDOR findings by the data behind the object, assign an owner and a deadline, and retest the fix.

Frequently Asked Questions

What is an IDOR vulnerability?

An IDOR (insecure direct object reference) vulnerability is an access control flaw in which an application uses an identifier supplied in the request, such as an order number, user ID or file name, to fetch an object without checking that the caller is allowed to access it. By changing the identifier, a signed-in user can read, modify or delete data that belongs to someone else. OWASP describes three ingredients: an object, a reference to it, and a missing object-level authorization check.

What is the difference between IDOR and BOLA?

They describe the same failure. IDOR is the older web application term, which was its own OWASP Top 10 category from 2007 to 2013, and BOLA (broken object level authorization) is the name the OWASP API Security Top 10 uses, where it is ranked API1:2023. MITRE's CWE-639 lists both as alternate terms, with the note that BOLA may also apply to related weaknesses. A report that names either one is pointing at a missing ownership check.

Is IDOR in the OWASP Top 10?

Yes, inside a broader category. IDOR was a standalone entry (A4) in the 2007, 2010 and 2013 lists and has since been part of broken access control, which is ranked number one (A01) in the OWASP Top 10:2025. That category lists viewing or editing someone else's account by providing its unique identifier among its common failures and maps CWE-639 among its 40 weaknesses.

Can a vulnerability scanner find IDOR?

Rarely on its own. A scanner sees a valid request and a valid response and has no way to know that the object returned belongs to a different user. CISA, the NSA and the Australian Cyber Security Centre note that not all DAST tools can detect IDOR vulnerabilities, that those which can may need specific configuration and custom rules, and that they should be used alongside other testing methods. Reliable detection needs several accounts and knowledge of who should be able to reach what.

Do UUIDs prevent IDOR?

No. Random identifiers make guessing impractical, which is useful as defense in depth, but identifiers leak through links, logs, exports and other API responses, and a server that returns any object to anyone who knows its ID is still vulnerable. CISA's guidance states that UUIDs and GUIDs should not be used for security capabilities. The Langflow flaw CVE-2026-55255, which CISA added to its Known Exploited Vulnerabilities catalog on 7 July 2026, was an IDOR on a UUID.

How do you fix an IDOR vulnerability?

Add a server-side authorization check to every operation on every object, so the application confirms that the object belongs to the caller or the caller's tenant before it reads, changes, deletes or exports it. The most reliable way is to scope database lookups to the authenticated user or tenant, take identity from the session instead of the request, enforce the rule in a central policy layer that denies by default, and add automated tests that request one account's objects as another account.

How is IDOR tested in a penetration test?

The tester agrees the access rules with the application owner, sets up at least two accounts per role and, for multi-tenant products, two tenants, then records every request that carries an object reference and replays it under each of the other identities. Any request that returns or changes an object the rule says should be denied is a finding. The check is repeated for read, create, update, delete and export operations and on every interface, including mobile and internal APIs.

How serious is an IDOR vulnerability?

Severity depends on the data or function behind the object. The vendor-rated cases in this guide range from 5.4 (Medium) for Cisco Slido to 9.1 (Critical) for SolarWinds Serv-U, and the First American Financial flaw involved a repository of approximately 800 million document images. In Stingrai's State of Penetration Testing 2026 dataset, 24.2% of IDOR findings were rated Critical.

A missing ownership check is cheap to fix and expensive to discover late. To have your application's authorization tested across every role and tenant, book a 30-minute scoping call or get a quote.

Related reading

• Why Automated API Scanners Miss BOLA and IDOR

• API Authorization Test Matrix 2026: What a Buyer Should Ask to See

• Multi-Tenant SaaS Penetration Test Scope: A Buyer Guide

• OWASP Top 10 2025: The Full List, What Changed and How to Test Each Risk

• How Big Is an Authorization Fix? Patch Size by Weakness Family

• The Dark Side of Next.js Server Actions: How Hidden Actions Can Bypass Your Access Controls

• State of Penetration Testing 2026

• API Penetration Testing Checklist: What to Test, Prepare and Expect (2026)

• OWASP Mobile Top 10 (2024): What Each Risk Means and How a Penetration Test Checks It

• Vibe Coding Security Checklist: 24 Checks for AI-Built Apps Before Launch

• Cross-Site Scripting (XSS): Real Examples, How Testers Find It and How to Fix It

• Web Application Penetration Testing: What It Is, What It Tests and How It Works (2026)

• Best Web Application Penetration Testing Companies (2026): Services Compared

References

1. CISA, NSA and ACSC. Preventing Web Application Access Control Abuse (AA23-208A), 27 July 2023.

2. OWASP. Insecure Direct Object Reference Prevention Cheat Sheet.

3. OWASP. A01:2025 Broken Access Control, OWASP Top 10:2025.

4. OWASP. API1:2023 Broken Object Level Authorization, OWASP API Security Top 10 2023.

5. OWASP. Testing for Insecure Direct Object References (WSTG-ATHZ-04), Web Security Testing Guide v4.2.

6. OWASP. Application Security Verification Standard 5.0, V8 Authorization.

7. MITRE. CWE-639: Authorization Bypass Through User-Controlled Key.

8. MITRE. 2025 CWE Top 25 Most Dangerous Software Weaknesses.

9. US Securities and Exchange Commission. In the Matter of First American Financial Corporation, Release No. 92176, 14 June 2021, and press release 2021-102, 15 June 2021.

10. CERT Coordination Center. VU#229438: Mobile device monitoring services do not authenticate API requests, 22 February 2022.

11. Paradox. Responsible Security Update, 9 July 2025.

12. Ian Carroll and Sam Curry. Would you like an IDOR with that? Leaking 64 million McDonald's job applications, 2025.

13. Cisco. Cisco Slido Insecure Direct Object Reference Vulnerability (cisco-sa-slido-idor-CpsFmKxN), 6 May 2026.

14. Langflow. GHSA-qrpv-q767-xqq2: IDOR vulnerability in the responses endpoint (CVE-2026-55255), 19 June 2026.

15. CISA. Known Exploited Vulnerabilities Catalog, version 2026.11.10.

16. SolarWinds. Serv-U Insecure Direct Object Reference (IDOR) Vulnerability (CVE-2026-28317), 21 July 2026.

17. Stingrai. State of Penetration Testing 2026.