Pith. sign in

REVIEW 4 major objections 5 minor 2 cited by

Unveiling the Landscape of LLM Deployment in the Wild: An Empirical Study

T0 review · 4 major / 5 minor · reviewed 2026-08-16 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Internet-wide scanning finds 320,102 public-facing LLM services with widespread weak or missing security, including over 40% on plain HTTP and unauthenticated API leaks of model data.

desk verdict Broad new map of exposed LLM services, but the census total over-counts via generic fingerprints; the qualitative findings hold and the paper merits review. read the letter →

arxiv 2505.02502 v2 pith:GDTXQXPP submitted 2025-05-05 cs.CR cs.AIcs.SE

Xinyi Hou , Jiahao Han , Yanjie Zhao , Haoyu Wang This is my paper · ORCID
classification cs.CRcs.AIcs.SE
keywords LLMdeploymentsecurityinternet-widemeasurementFOFAOllamaAPIexposureTLSmisconfigurationunauthenticatedaccesssecure-by-default
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper attempts to establish that self-hosted large language model deployments are widely exposed to the public internet with insecure defaults. Using the FOFA asset search engine, it enumerates 320,102 public-facing services across 15 deployment frameworks and, after probing 158 documented API endpoints, finds that more than 40% of endpoints use plain HTTP, over 210,000 endpoints lack valid TLS metadata, and frameworks such as Ollama respond to more than 35% of unauthenticated API requests, with about 15% leaking model or system information. The authors argue these problems are systemic, not isolated accidents, and that they produce concrete risks of model theft, resource abuse, and system compromise. The study matters because it gives the first large-scale quantitative map of the self-hosted LLM attack surface and points to specific defaults that turn local tools into public liabilities.

What carries the argument

The central machinery is a four-step measurement pipeline. FOFA—an internet-wide asset search engine that indexes IPs, domains, ports, and service metadata—is queried using 15 hand-built feature catalogs (default ports, page titles, HTTP headers, favicon hashes) to enumerate candidate LLM services. The 158 official-documentation API endpoints are then probed unauthenticated over HTTP(S), and each response is mapped to a unified five-field schema (framework, category, endpoint, response type, security relevance) grouped into 12 functional categories. This pipeline converts the observation that many hosts exist into evidence that specific endpoints answer without credentials, which is the load-bearing support for the paper's security conclusions.

What would settle it

Re-run the same FOFA queries on a fresh sample, fetch each matched host's landing page, and send one framework-specific API request per host; if many matched hosts do not actually serve LLM functionality, or if Ollama's 'template responses' turn out to be generic reverse-proxy pages rather than Ollama runtime answers, then the 320,102 census and the reported response rates overstate the true exposure.

Watch

Extended reading notes

Core claim

The paper's central claim is that a large share of self-hosted LLM services on the public internet are reachable without authentication and often without encryption. The authors identify 320,102 public LLM services across 15 frameworks using hand-built FOFA signatures, extract 158 unique API endpoints grouped into 12 functional categories, and probe them with unauthenticated HTTP(S) requests. They report that over 40% of endpoints served plain HTTP, more than 210,000 endpoints lacked valid TLS metadata, and response rates varied widely by framework: Ollama and Llamafile answered over 10% of unauthenticated API calls, with Ollama leaking model or system information in roughly 15% of cases, while Open WebUI, NextChat, and Gradio answered below 0.1%. The paper interprets these findings as evidence that frameworks favor ease of deployment over secure defaults and that the resulting exposure enables model information disclosure, system configuration disclosure, unauthorized resource abuse, and potential system compromise.

Load-bearing premise

The census counts every host matching a framework's FOFA signature as an LLM service, so the entire exposure statistics rest on the unquantified assumption that signatures such as 'title=FastAPI' or 'body=Jupyter Notebook' select LLM deployments rather than any other web application built with those tools.

Editorial extensions

If this is right

  • If the census is right, the self-hosted LLM attack surface already numbers in the hundreds of thousands and is concentrated among a few cloud providers, so remediating high-density hosting domains and default images would shrink the exposed surface substantially.
  • If over 40% of endpoints use plain HTTP, passive network observers and on-path attackers can read or tamper with prompts and generated text for a large share of deployments.
  • If Ollama and Llamafile answer unauthenticated API calls at rates above 10%, then default installations of these frameworks effectively provide open model-listing, model-loading, and system-status endpoints to anyone on the internet.
  • If ComfyUI exposes endpoints in every risk category, then even a framework that looks like a niche UI tool becomes a systemic risk when its default bind address is 0.0.0.0 with no authentication, directly connecting model-hosting nodes to remote code execution and GPU abuse.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A stricter active re-measurement that requires a successful LLM-specific API response from each host would likely shrink the raw census number, because the FastAPI and Jupyter Notebook signatures match generic tools; the ordering of frameworks by exposure is nonetheless likely to survive such a re-test.
  • The observed 'template responses' for Ollama suggest that part of the 35% response rate is produced by reverse proxies, load balancers, or defensive honeypots rather than by the LLM runtime itself, so the paper's 15.28% 'without template' rate is the safer upper bound for genuine leakage.
  • The 158 endpoints and 12 functional categories form a ready-made probe list; building a scanner around them and running it on new deployments would test whether the recommended secure-by-default changes actually reduce exposure over time.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper reports a large-scale internet measurement of publicly accessible LLM deployments. Using FOFA queries built from per-framework feature catalogs, the authors claim to have identified 320,102 public-facing LLM services across 15 frameworks, extracted 158 API endpoints in 12 functional categories, and probed these endpoints to characterize unauthenticated access, TLS usage, certificate hygiene, and security risk patterns. The central qualitative finding is that many self-hosted LLM deployments are reachable without authentication or transport encryption, with Ollama and ComfyUI highlighted as especially permissive. The paper concludes with secure-by-default recommendations for framework developers, operators, and the broader ecosystem.

Significance. If the quantitative claims survive scrutiny, this would be a useful and timely measurement study of a rapidly evolving ecosystem. The paper's strengths include a reproducible artifact repository, a transparent four-step methodology (framework selection, FOFA discovery, endpoint probing, risk analysis), and per-framework endpoint catalogs that can inform future audits. The Ollama-specific finding that a large share of public instances respond to unauthenticated model-management calls is credible and consistent with prior independent measurements. The novelty lies in the breadth of the census and the systematic risk taxonomy, rather than in a new attack or defensive technique. However, the significance is currently bounded by the unquantified precision of the discovery signatures and by unresolved numerical inconsistencies in the reported totals.

major comments (4)
  1. [Section III-B and Table I] The census total of 320,102 is built on signatures that are not LLM-specific. Two of the largest non-Ollama contributions use generic fingerprints: Jupyter Notebook (24,531 hits via body=Jupyter Notebook) and FastAPI (4,526 hits via title/body FastAPI plus ports 8000/8080). These identify any Jupyter or FastAPI web application, not only LLM deployments. The manuscript states that queries were refined and 'a representative subset' was manually validated, but no per-signature precision, validation sample size, or confirmation criteria are reported. Because the headline percentages ('over 40% plain HTTP', 'over 210,000 without valid TLS metadata') are computed over this census, unknown numbers of non-LLM hosts enter both numerators and denominators. Please report per-signature precision and recall estimates, or restrict the census and all derived rates to frameworks with LLM-specific fingerprints.
  2. [Section IV-A and answer to RQ1] The dataset totals are not reconciled: the abstract and Table I report 320,102, while Section IV-A and the RQ1 answer report 320,012. Table IV uses sample denominators that do not match Table I (e.g., Open WebUI 43,947 vs 37,242; Jan 380 vs 28,445; NextChat 20,000 vs 25,883), and Table VII reports 155,424 invocations while Table I lists 155,423 Ollama services. This makes it impossible to determine which denominator each response rate is computed against and undermines the quantitative precision of the main claims. Please reconcile the totals and state the sampling universe, sample size, and weighting procedure for every reported rate.
  3. [Section III-C and Table IV] The definition and detection of 'template responses' is not specified. The Ollama response rate changes from 35.23% to 15.28% when these are excluded, and the 14.69% full-dataset rate is used to validate that exclusion. Without a concrete criterion (e.g., exact-body matching or content hashing) and evidence that the same criterion was applied consistently to other frameworks, the reported framework-level responsiveness and the statement that template responses were not observed elsewhere are not verifiable. Please define the criterion, quantify how many responses per framework fall into it, and report rates both with and without such responses.
  4. [Section III-B and Section IV-A] The paper does not quantify the precision of the FOFA queries used to enumerate many of the frameworks in Table I, nor does it define what constitutes a distinct service. The high-traffic-domain analysis shows thousands of instances behind shared IPs and certificates (e.g., 6,206 instances under nellasushi.es served by two IPs), which raises the possibility that the same logical deployment is counted multiple times. Please state how unique services are defined, how duplicate records or multi-instance hosts are handled, and how this affects the geographic, organizational, and rate-based analyses.
minor comments (5)
  1. [Abstract and Section IV-A] The phrase 'over 210,000 endpoints lacked valid TLS metadata' conflates certificate validity with certificate subject naming; Section IV-A-5 actually analyzes subject CNs such as localhost and nan, which does not establish that TLS is absent or invalid. Please clarify the TLS measurement and use consistent terminology.
  2. [Section II-A] There is a typo in the first paragraph: 'OW ASP' should be 'OWASP'.
  3. [Table V] The cells reporting 'successful / total' are ambiguous because the denominator includes endpoints that were never probed for a given framework; please clarify whether 'total' denotes probed endpoints or all documented endpoints.
  4. [Section III-B] The FOFA feature catalog in Table I lists key features and counts but does not provide the exact query expressions used for each framework; making the full query set available in the artifact would improve reproducibility.
  5. [Table VII] The note says 'Based on 155,424 sampled LLM service invocations', but an invocation count is not the same as a unique service count; please clarify whether the denominator is unique services or probe attempts.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: the paper is an externally grounded measurement study whose claims are computed from internet-wide scans, not from its own assumptions.

full rationale

This paper is an empirical measurement study, not a derivation. The central claims—counts of public-facing services, TLS/HTTP usage, and unauthenticated API response rates—are computed from FOFA scan results and HTTP probes against internet hosts, which are external ground-truth observations. The framework-selection and FOFA query construction are input choices, and the reported percentages are arithmetic summaries of the resulting dataset; there is no fitted parameter that is later renamed as a prediction, and no quantity is defined in terms of the conclusion it supports. The only self-citations (refs. [16] and [17]) appear in the introduction and related work as background examples and are not load-bearing for the measurement or risk analysis. The paper's own threats-to-validity section acknowledges limited framework coverage and sampling. The skeptic's concern about generic Jupyter/FastAPI signatures in Table I is a legitimate external-validity threat (unquantified false-positive rate), not a circularity: a false positive would bias the counts, but it would not make the reported numbers equivalent to the paper's inputs by construction. The Ollama template-response exclusion is a transparent post-hoc data-cleaning choice reported with both rates, and it adjusts a measurement rather than inventing a prediction. Accordingly, no circular step can be exhibited, and the circularity score is 0.

Assumptions & free parameters 3 free parameters · 3 assumptions · 0 invented entities

The central numbers rest on hand-built discovery signatures, a single search-engine source, a non-uniform sampling plan, and an ad hoc template-response filter; none is independently validated, so they are logged as free parameters and domain assumptions rather than neutral background facts.

free parameters (3)
  • Per-framework FOFA query signatures
    Each framework is identified by hand-chosen feature catalogs (default ports, title keywords, HTTP headers, favicon hashes) in Table I and Section III-B; false-positive rates are unquantified, and signatures such as title=FastAPI capture general-purpose services that may not be LLM deployments.
  • Ollama probe sample size = 877
    Probing of Ollama was limited to a random sample of 877 of 155,423 instances (Section IV-B1); other frameworks were sampled at different rates (Jan 380, NextChat 20,000) without a stated uniform protocol.
  • 'Template response' exclusion criterion
    Ollama's response rate is reported with (35.23%) and without (15.28%) 'template responses'; the exclusion is described only as 'generic, uninformative replies' with a speculative cause and is applied to Ollama only (Section IV-B1).
assumptions (3)
  • domain assumption FOFA's index and query results are complete and representative of the public internet
    The entire census is built on FOFA query results (Section III-B), with no cross-validation against Censys, Shodan, or ZoomEye; coverage and freshness bias are unmeasured.
  • domain assumption The 15 selected frameworks represent the LLM deployment ecosystem
    Selection in Section III-A used popularity, documentation quality, and 'unique network exposure patterns'; the authors acknowledge limited coverage in Section V-B but still generalize to 'the LLM ecosystem' in the conclusion.
  • domain assumption Read-only probing of public endpoints does not alter service state and is ethically acceptable at this scale
    Section V-C asserts non-destructive, read-only behavior, but no rate limits, retry policy, or opt-out handling are reported, and tens of thousands of hosts were probed.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Unveiling the Landscape of LLM Deployment in the Wild: An Empirical Study." pith.science (2026). https://pith.science/paper/GDTXQXPP

@misc{pith2026250502502,
  author       = {Pith},
  title        = {Pith review of: Unveiling the Landscape of LLM Deployment in the Wild: An Empirical Study},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/GDTXQXPP}},
  note         = {Machine review of arXiv:2505.02502}
}
read the original abstract

Large language models (LLMs) are increasingly deployed through open-source and commercial frameworks, enabling individuals and organizations to self-host advanced LLM capabilities. As LLM deployments become prevalent, particularly in industry, ensuring their secure and reliable operation has become a critical issue. However, insecure defaults and misconfigurations often expose LLM services to the public internet, posing serious security and system engineering risks. This study conducted a large-scale empirical investigation of public-facing LLM deployments, focusing on the prevalence of services, exposure characteristics, systemic vulnerabilities, and associated risks. Through internet-wide measurements, we identified 320,102 public-facing LLM services across 15 frameworks and extracted 158 unique API endpoints, categorized into 12 functional groups based on functionality and security risk. Our analysis found that over 40% of endpoints used plain HTTP, and over 210,000 endpoints lacked valid TLS metadata. API exposure was highly inconsistent: some frameworks, such as Ollama, responded to over 35% of unauthenticated API requests, with about 15% leaking model or system information, while other frameworks implemented stricter controls. We observed widespread use of insecure protocols, poor TLS configurations, and unauthenticated access to critical operations. These security risks, such as model leakage, system compromise, and unauthorized access, are pervasive and highlight the need for a secure-by-default framework and stronger deployment practices.

Figures

Figures reproduced from arXiv: 2505.02502 by the authors.

Figure 1
Figure 1. Overview of the Empirical Analysis Pipeline. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Global Landscape of Public LLM Deployment. [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. High-Traffic Domains by Number of LLM Services. [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Distribution of LLM Services Across Ports by Deployment Framework. [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: TLS Version Distribution Across Ports (Log Scale). [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]
Figure 6
Figure 6. Figure 6: Distribution of Reused TLS Certificate Subject CNs. [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. When Models Meet Users: An Empirical Study of Perceptions of General LLMs and Multimodal LLMs on Hugging Face

    cs.SE 2026-04 unverdicted novelty 5.0 of 10

    Hugging Face discussions show that access barriers, output quality, and setup complexity are the main user concerns for both general and multimodal LLMs.

  2. Software Engineering for Large Language Models: Research Status, Challenges and the Road Ahead

    cs.SE 2025-06 conditional novelty 4.0 of 10

    A literature review organizes LLM development into a six-phase software engineering lifecycle and identifies challenges and research directions for each phase.

Reference graph

Works this paper leans on

50 extracted references · 32 canonical work pages · cited by 2 Pith papers

  1. [1]

    Automated unit test improvement using large language models at meta,

    N. Alshahwan, J. Chheda, A. Finogenova, B. Gokkaya, M. Harman, I. Harper, A. Marginean, S. Sengupta, and E. Wang, “Automated unit test improvement using large language models at meta,” in Companion Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering , ser. FSE 2024. New York, NY , USA: Association for Computing ...

    arXiv 2024

  2. [2]

    Awesome free ollama,

    Anonymous, “Awesome free ollama,” https://freeollama.oneplus1.top, 2024

    work page 2024

  3. [3]

    Demystifying platform requirements for diverse llm inference use cases,

    A. Bambhaniya, R. Raj, G. Jeong, S. Kundu, S. Srinivasan, M. Elavazha- gan, M. Kumar, and T. Krishna, “Demystifying platform requirements for diverse llm inference use cases,” arXiv preprint arXiv:2406.01698 , 2024

    arXiv 2024

  4. [4]

    Unveiling the vulnerability of private fine-tuning in split-based frameworks for large language models: A bidirectionally enhanced attack,

    G. Chen, Z. Qin, M. Yang, Y . Zhou, T. Fan, T. Du, and Z. Xu, “Unveiling the vulnerability of private fine-tuning in split-based frameworks for large language models: A bidirectionally enhanced attack,” in Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security , ser. CCS ’24. New York, NY , USA: Association for Computing ...

    arXiv 2024

  5. [5]

    An agile framework for efficient llm accelerator development and model inference,

    L. Chen, Y . Wu, C. Wen, S. Wang, L. Zhang, B. Yu, Q. Sun, and C. Zhuo, “An agile framework for efficient llm accelerator development and model inference,” in Proceedings of the 43rd IEEE/ACM International Conference on Computer-Aided Design , ser. ICCAD ’24. New York, NY , USA: Association for Computing Machinery, 2025. [Online]. Available: https://doi.o...

    arXiv 2025

  6. [6]

    Why are web ai agents more vulnerable than standalone llms? a security analysis,

    J. Y . F. Chiang, S. Lee, J.-B. Huang, F. Huang, and Y . Chen, “Why are web ai agents more vulnerable than standalone llms? a security analysis,” arXiv preprint arXiv:2502.20383 , 2025

    arXiv 2025

  7. [7]

    Fofa: Cyberspace asset search engine,

    W. H. Community, “Fofa: Cyberspace asset search engine,” https://fofa. info/, 2024

    work page 2024

  8. [8]

    Nextchat,

    N. Contributors, “Nextchat,” https://github.com/ChatGPTNextWeb, 2024

    work page 2024

Show all 50 references
  1. [9]

    Deepseek llm,

    DeepSeek-AI, “Deepseek llm,” https://github.com/deepseek-ai, 2025

    2025

  2. [10]

    Comfyui,

    C. Developers, “Comfyui,” https://github.com/comfyanonymous/ ComfyUI, 2024

    2024

  3. [11]

    Llm-aid: Leveraging large language models for rapid domain-specific accelerator development,

    F. Firouzi, S. S. R. Nakkilla, C. Fu, S. Banerjee, J. Talukdar, and K. Chakrabarty, “Llm-aid: Leveraging large language models for rapid domain-specific accelerator development,” in Proceedings of the 43rd IEEE/ACM International Conference on Computer-Aided Design , ser. ICCAD...

    2025 doi

  4. [12]

    Owasp top 10 for llm applications 2025,

    O. Foundation, “Owasp top 10 for llm applications 2025,” https://genai. owasp.org/resource/owasp-top-10-for-llm-applications-2025/, 2024

    2025

  5. [13]

    llama.cpp,

    G. Gerganov, “llama.cpp,” https://github.com/ggerganov/llama.cpp, 2024

    2024

  6. [14]

    Not what you’ve signed up for: Compromising real- world llm-integrated applications with indirect prompt injection,

    K. Greshake, S. Abdelnabi, S. Mishra, C. Endres, T. Holz, and M. Fritz, “Not what you’ve signed up for: Compromising real- world llm-integrated applications with indirect prompt injection,” in Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security , ser. ...

    2023

  7. [15]

    The emerged security and privacy of llm agent: A survey with case studies,

    F. He, T. Zhu, D. Ye, B. Liu, W. Zhou, and P. S. Yu, “The emerged security and privacy of llm agent: A survey with case studies,” arXiv preprint arXiv:2407.19354, 2024

    2024

  8. [16]

    Large language models for software engineering: A systematic literature review,

    X. Hou, Y . Zhao, Y . Liu, Z. Yang, K. Wang, L. Li, X. Luo, D. Lo, J. Grundy, and H. Wang, “Large language models for software engineering: A systematic literature review,” ACM Trans. Softw. Eng. Methodol. , vol. 33, no. 8, Dec. 2024. [Online]. Available: https://doi.org/10.11...

    2024 doi

  9. [17]

    The next frontier of llm ap- plications: Open ecosystems and hardware synergy,

    X. Hou, Y . Zhao, and H. Wang, “The next frontier of llm ap- plications: Open ecosystems and hardware synergy,” arXiv preprint arXiv:2503.04596, 2025

    2025

  10. [18]

    What’s important here?: Opportunities and challenges of llm in retrieving information from web interface,

    F. Huq, J. P. Bigham, and N. Martelaro, “What’s important here?: Opportunities and challenges of llm in retrieving information from web interface,” R0-FoMo: Robustness of Few-shot and Zero-shot Learning in Large Foundation Models, 2023

    2023

  11. [19]

    Ray serve,

    A. Inc., “Ray serve,” https://docs.ray.io/en/latest/serve/index.html, 2024

    2024

  12. [20]

    Isachenko and S

    T. Isachenko and S. Bhuiyan, Generative AI with local LLM . Timur Isachenko, 2024

    2024

  13. [21]

    Jupyter notebook,

    P. Jupyter, “Jupyter notebook,” https://jupyter.org/, 2024

    2024

  14. [22]

    Llm-pilot: Characterize and opti- mize performance of your llm inference services,

    M. Lazuka, A. Anghel, and T. Parnell, “Llm-pilot: Characterize and opti- mize performance of your llm inference services,” inSC24: International Conference for High Performance Computing, Networking, Storage and Analysis. IEEE, 2024, pp. 1–18

    2024

  15. [23]

    Commercial llm agents are already vulnerable to simple yet dangerous attacks,

    A. Li, Y . Zhou, V . C. Raghuram, T. Goldstein, and M. Goldblum, “Commercial llm agents are already vulnerable to simple yet dangerous attacks,” arXiv preprint arXiv:2502.08586 , 2025

    2025 arXiv

  16. [24]

    Llm inference serv- ing: Survey of recent advances and opportunities,

    B. Li, Y . Jiang, V . Gadepally, and D. Tiwari, “Llm inference serv- ing: Survey of recent advances and opportunities,” arXiv preprint arXiv:2407.12391, 2024

    2024 arXiv

  17. [25]

    Shodan: The search engine for internet-connected devices,

    S. LLC, “Shodan: The search engine for internet-connected devices,” https://www.shodan.io/, 2024

    2024

  18. [26]

    Web llm attacks: Unveiling the future of cyber threats,

    F. Mohammad Ali Pour and M. Rashidi, “Web llm attacks: Unveiling the future of cyber threats,” Available at SSRN 5049058 , 2024

    2024

  19. [27]

    Apache http server 2.4.29 vulnerabilities,

    NIST National Vulnerability Database, “Apache http server 2.4.29 vulnerabilities,” https://nvd.nist.gov/vuln/detail/CVE-2019-0211, 2024

    2019

  20. [28]

    Nginx 1.14.0 vulnerabilities,

    ——, “Nginx 1.14.0 vulnerabilities,” https://nvd.nist.gov/vuln/detail/ CVE-2019-20372, 2024

    2019

  21. [29]

    Gpt4all,

    Nomic-AI, “Gpt4all,” https://github.com/nomic-ai/gpt4all, 2024

    2024

  22. [30]

    Cve-2024-37032: Ollama remote code execution vulnerability,

    N. V . D. (NVD), “Cve-2024-37032: Ollama remote code execution vulnerability,” https://nvd.nist.gov/vuln/detail/CVE-2024-37032, 2024

    2024

  23. [31]

    Cve-2024-6707: Openwebui arbitrary file upload vulnerability,

    ——, “Cve-2024-6707: Openwebui arbitrary file upload vulnerability,” https://nvd.nist.gov/vuln/detail/CVE-2024-6707, 2024

    2024

  24. [32]

    Text generation web ui,

    oobabooga, “Text generation web ui,” https://github.com/oobabooga/ text-generation-webui, 2024

    2024

  25. [33]

    Introducing openai o3 and o4-mini,

    OpenAI, “Introducing openai o3 and o4-mini,” https://openai.com/index/ introducing-o3-and-o4-mini, 2025

    2025

  26. [34]

    Security considerations for large language model use: Imple- mentation research in securing llm-integrated applications,

    N. Pesati, “Security considerations for large language model use: Imple- mentation research in securing llm-integrated applications,” Available at SSRN 4962370, 2024

    2024

  27. [35]

    Llamafile,

    C. Project, “Llamafile,” https://github.com/Mozilla-Ocho/llamafile, 2024

    2024

  28. [36]

    Fastapi/swagger ui,

    S. Ram ´ırez, “Fastapi/swagger ui,” https://fastapi.tiangolo.com/, 2024

    2024

  29. [37]

    Building ai agents for autonomous clouds: Challenges and design principles,

    M. Shetty, Y . Chen, G. Somashekar, M. Ma, Y . Simmhan, X. Zhang, J. Mace, D. Vandevoorde, P. Las-Casas, S. M. Gupta, S. Nath, C. Bansal, and S. Rajmohan, “Building ai agents for autonomous clouds: Challenges and design principles,” in Proceedings of the 2024 ACM Symposium on ...

    2024

  30. [38]

    Anythingllm,

    A. Team, “Anythingllm,” https://github.com/Mintplex-Labs/ anything-llm, 2024

    2024

  31. [39]

    Team, “Gradio,” https://www.gradio.app/, 2024

    G. Team, “Gradio,” https://www.gradio.app/, 2024

    2024

  32. [40]

    Team, “Jan,” https://github.com/janhq/jan, 2024

    J. Team, “Jan,” https://github.com/janhq/jan, 2024

    2024

  33. [41]

    Zoomeye: Cyberspace search engine,

    K. . Team, “Zoomeye: Cyberspace search engine,” https://www. zoomeye.org/, 2024

    2024

  34. [42]

    Team, “Ollama,” https://ollama.com, 2024

    O. Team, “Ollama,” https://ollama.com, 2024

    2024

  35. [43]

    Open webui,

    O. W. Team, “Open webui,” https://github.com/open-webui/open-webui, 2024

    2024

  36. [44]

    vLLM Team, “vllm,” https://github.com/vllm-project/vllm, 2024

    2024

  37. [45]

    Wipi: A new web threat for llm- driven web agents,

    F. Wu, S. Wu, Y . Cao, and C. Xiao, “Wipi: A new web threat for llm- driven web agents,” arXiv preprint arXiv:2402.16965 , 2024

    2024 arXiv

  38. [46]

    A new era in llm security: Exploring security concerns in real-world llm-based systems,

    F. Wu, N. Zhang, S. Jha, P. McDaniel, and C. Xiao, “A new era in llm security: Exploring security concerns in real-world llm-based systems,” arXiv preprint arXiv:2402.18649 , 2024

    2024 arXiv

  39. [47]

    I know what you asked: Prompt leakage via kv-cache sharing in multi- tenant llm serving,

    G. Wu, Z. Zhang, Y . Zhang, W. Wang, J. Niu, Y . Wu, and Y . Zhang, “I know what you asked: Prompt leakage via kv-cache sharing in multi- tenant llm serving,” in Proceedings of the 2025 Network and Distributed System Security (NDSS) Symposium. San Diego, CA, USA , 2025

    2025

  40. [48]

    Open-finllms: Open multimodal large language models for financial applications,

    Q. Xie, D. Li, M. Xiao, Z. Jiang, R. Xiang, X. Zhang, Z. Chen, Y . He, W. Han, Y . Yanget al., “Open-finllms: Open multimodal large language models for financial applications,” arXiv preprint arXiv:2408.11878 , 2024

    2024 arXiv

  41. [49]

    Controlnet: A firewall for rag-based llm system,

    H. Yao, H. Shi, Y . Chen, Y . Jiang, C. Wang, Z. Qin, K. Ren, and C. Chen, “Controlnet: A firewall for rag-based llm system,” arXiv preprint arXiv:2504.09593, 2025

    2025 arXiv

  42. [50]

    A survey on large language model (llm) security and privacy: The good, the bad, and the ugly,

    Y . Yao, J. Duan, K. Xu, Y . Cai, Z. Sun, and Y . Zhang, “A survey on large language model (llm) security and privacy: The good, the bad, and the ugly,” High-Confidence Computing, p. 100211, 2024

    2024

Pith tools

Reviewed August 16, 2026 · model on record in the stance chip above.