Paper deep dive

Polar: LLM-Powered Synthesis of Real-World Cyber Evidence for Prioritization and Mitigation

Luoxi Tang, Yuqiao Meng, Ankita Patra, Weicheng Ma, Muchao Ye, Zhaohan Xi

Year: 2026Venue: arXiv preprintArea: cs.CRType: PreprintEmbeddings: 102

Intelligence

Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 92%

Last extracted: 10/7/2026, 9:04:52 AM

Summary

The paper introduces POLAR, an LLM-powered framework designed to synthesize fragmented real-world cyber evidence (from vendor advisories, vulnerability databases, and threat intelligence) into structured, threat-centric assessments. POLAR disentangles overlapping incidents, grounds them in source-linked evidence, and performs two main tasks: prioritization (inferring CVSS severity and estimating near-term exploitation likelihood based on temporal signals) and mitigation (recommending authoritative remediation actions based on threat urgency and operational constraints). The framework is evaluated on real-world vulnerability data, demonstrating improved threat ranking and mitigation retrieval compared to baselines.

Entities (9)

POLAR · framework · 98%LLM · technology · 97%Binghamton University · organization · 95%CISA KEV · database · 95%Exploit-DB · database · 95%MITRE ATT&CK · knowledge-base · 93%CVSS · standard · 92%EPSS · standard · 90%Jenkins · software · 90%

Relation Signals (9)

POLAR → uses → LLM

confidence 98% · We present POLAR, an LLM-powered framework for synthesizing real-world cyber evidence

POLAR → performstask → Threat Prioritization

confidence 95% · For prioritization, it infers severity metrics from cyber evidence and combines the resulting assessment with temporally ordered exploitation signals

POLAR → performstask → Mitigation Recommendation

confidence 95% · For mitigation, it links the synthesized threat data to authoritative remediation knowledge and organizes applicable actions

POLAR → usesdatasource → Exploit-DB

confidence 95% · cross-referencing evidence from Exploit-DB

POLAR → usesdatasource → CISA KEV

confidence 95% · cross-referencing evidence from ... CISA KEV

POLAR → usesknowledgebase → MITRE ATT&CK

confidence 93% · retrieves complementary evidence from external sources ... ATT&CK knowledge

POLAR → infersmetric → CVSS

confidence 92% · It derives CVSS metrics from evidence specific to each severity dimension

POLAR → estimatesprobability → EPSS

confidence 90% · estimate near-term exploitation likelihood ... following the prediction horizon used by EPSS

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract:Cyber threat analysis increasingly depends on evidence distributed across vendor advisories, vulnerability databases, and threat intelligence sources. Turning these fragmented observations into timely decisions requires models to connect technical severity with evolving exploitation evidence and available defensive actions. We present POLAR, an LLM-powered framework for synthesizing real-world cyber evidence into threat-centric assessments for prioritization and mitigation. POLAR first disentangles overlapping incidents and grounds each threat in source-linked evidence. For prioritization, it infers severity metrics from cyber evidence and combines the resulting assessment with temporally ordered exploitation signals to estimate near-term exploitation likelihood. For mitigation, it links the synthesized threat data to authoritative remediation knowledge and organizes applicable actions according to threat urgency and operational constraints. We evaluate POLAR on real-world vulnerability evidence collected from public resources and compare it with multiple baselines. Across heterogeneous incidents and zero-day settings, POLAR improves threat ranking and mitigation retrieval while producing evidence-linked intermediate assessments that support analyst inspection. The results establish evidence synthesis as a practical foundation for LLM-based cyber decision support across related security tasks.

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

98,551 characters extracted from source content.

Expand or collapse full text

Polar: LLM-Powered Synthesis of Real-World Cyber Evidence for Prioritization and Mitigation Luoxi Tang Yuqiao Meng Ankita Patra Weicheng Ma Muchao Ye Zhaohan Xi Email: ltang24,ymeng15,zxi1@binghamton.edu Affiliation: Binghamton University, State University of New York, Binghamton, NY, USA Affiliation: Oakland University, Rochester, MI, USA Affiliation: University of Iowa, Iowa City, IA, USA Abstract Cyber threat analysis increasingly depends on evidence distributed across vendor advisories, vulnerability databases, and threat intelligence sources. Turning these fragmented observations into timely decisions requires models to connect technical severity with evolving exploitation evidence and available defensive actions. We present Polar, an LLM-powered framework for synthesizing real-world cyber evidence into threat-centric assessments for prioritization and mitigation. Polar first disentangles overlapping incidents and grounds each threat in source-linked evidence. For prioritization, it infers severity metrics from cyber evidence and combines the resulting assessment with temporally ordered exploitation signals to estimate near-term exploitation likelihood. For mitigation, it links the synthesized threat data to authoritative remediation knowledge and organizes applicable actions according to threat urgency and operational constraints. We evaluate Polar on real-world vulnerability evidence collected from public resources and compare it with multiple baselines. Across heterogeneous incidents and zero-day settings, Polar improves threat ranking and mitigation retrieval while producing evidence-linked intermediate assessments that support analyst inspection. The results establish evidence synthesis as a practical foundation for LLM-based cyber decision support across related security tasks. 1 Introduction Cyber threat analysis increasingly depends on evidence that is fragmented across real-world security sources. A vulnerability may first appear in a vendor disclosure, later receive structured metadata in a vulnerability database, and then acquire new operational significance as exploitation evidence emerges. We use the term real-world cyber evidence to describe these observations and authoritative records as they accumulate around a threat. The central analytical problem is to turn this evolving evidence into decisions about threat urgency and remediation. Standard mechanisms such as the Common Vulnerability Scoring System (CVSS) (FIRST, 2019a; FIRST, 2019b) and the Exploit Prediction Scoring System (EPSS) (Jacobs et al., 2021b; Jacobs et al., 2019) provide useful views of severity and exploitation likelihood, yet threat analysis still requires evidence to be synthesized across sources and interpreted in context. Existing cyber analysis systems capture only part of this process. Rule-based tools and platforms are effective when signatures and decision rules are known (White et al., 2013; Sancho et al., 2020) . Their coverage weakens as threats and evidence evolve (Barr-Smith et al., 2021; Dong et al., 2023; Liu et al., 2024). Learning-based systems offer greater flexibility, including vulnerability classifiers (Almutairi, 2026; Zhan et al., 2021) and log-analysis models (Sasikrishna et al., 2026; Pakshad et al., 2026), though they commonly rely on fixed input representations and remain sensitive to shifts in CTI sources. A deeper limitation is that threat signals are often processed as isolated features. In practice, their meaning changes with context (Jørgensen and Ma, 2026). A moderate-severity vulnerability can become urgent after credible exploitation appears, while a high-severity vulnerability may pose limited immediate risk under restrictive exploitation conditions (Eling et al., 2023). Reliable analysis therefore depends on connecting evidence across technical and temporal context. Figure 1: A motivating example of different threat-prioritization workflows, wherein Polar synthesizes heterogeneous cyber evidence to support timely assessment and mitigation planning. Large language models (LLMs) offer opportunities for effective threat analysis given their capability to synthesize evidence expressed at different levels of abstraction (Nguyen et al., 2026), such as an authentication requirement in an advisory and a subsequent report of active exploitation. Recent work has applied LLMs to penetration testing (Deng et al., 2024), attack-path analysis (Prapty et al., 2024; Bahlibi et al., 2026; Meng et al., 2025b), and security-event reasoning (Uetz et al., 2024; Meng et al., 2025a). The remaining challenge is to organize this evidence before it is used for a decision. However, direct prompt-based agent design can conflate incidents or obscure the evidence that supports a conclusion (Ramachandran, 2026). This leads to our research question: How can LLMs synthesize heterogeneous real-world cyber evidence for structured assessments and downstream decisions? This Work. We present Polar (Figure 1), an LLM-powered framework that builds a threat-centric evidence profile from unstructured incidents and authoritative external sources. Polar separates overlapping threat descriptions, grounds each threat in source-linked metadata, and preserves evidence relevant to later analysis. This profile serves as the common input to two application scenarios studied in this work: (I) Prioritization: Polar combines two complementary assessments. It derives CVSS metrics from evidence specific to each severity dimension, then applies the official scoring procedure to obtain a standardized severity estimate. It also organizes exploitation evidence by time and uses the resulting history to estimate near-term exploitation likelihood. The combined view captures the consequence of successful exploitation together with the current evidence that exploitation may occur. (I) Mitigation: Polar connects the same threat profile to authoritative remediation knowledge and identifies actions applicable to the affected product and exploitation context. The resulting recommendations use the threat assessment and operational constraints to connect evidence of urgency with evidence for action. We evaluate Polar on real-world vulnerability data enriched with temporal threat events, covering a broad range of CVEs and cross-referencing evidence from Exploit-DB (Offensive Security, 2025), CISA KEV (Cybersecurity and Infrastructure Security Agency (CISA), 2024), VirusTotal (VirusTotal, 2004), and vendor advisories. Across comparisons with different baseline methods, Polar consistently improves threat prioritization and remains stable under entangled and heterogeneous incident settings. The gains are significant for high-severity threats with active or rapidly evolving exploitation evidence, where Polar produces more robust and timely prioritization. These results demonstrate the value of synthesizing heterogeneous real-world cyber evidence for decision support. Overall, this work makes several contributions: (1) We formulate real-world cyber evidence synthesis as a unified foundation for LLM-based prioritization and mitigation. (2) We develop Polar to organize heterogeneous cyber evidence into source-grounded threat assessments combining severity and exploitation dynamics. (3) We evaluate Polar across prioritization and mitigation tasks, showing consistent gains over multiple baseline methods. 2 Motivating Example Figure 1 uses a Jenkins vulnerability to illustrate the practical difficulty of threat prioritization. The vulnerability allows an unauthenticated attacker to read arbitrary files through crafted CLI requests. Soon after disclosure, public PoCs appear on Exploit-DB and GitHub, and attacker campaigns begin using the flaw for initial access and data exfiltration. The risk also varies across deployments because Jenkins instances may use different plug-ins and nonstandard configurations. A security team therefore needs to answer two questions quickly: How likely is this vulnerability to be exploited in the near term, and what should be mitigated first? Human team prioritization: An analyst would first read the vendor advisory and CTI reports, then check the available PoCs and compare them with the local Jenkins configuration. The analyst may also need to determine whether the exposed CLI path is reachable, whether installed plug-ins change the attack surface, and whether the observed campaign applies to the local environment. This process can produce a careful assessment, but it takes time. When hundreds of alerts arrive together, analysts must repeat the same cross-checking for many threats while new exploitation evidence continues to appear. The resulting delay can consume the short window in which preemptive patching is most useful. Conventional AI-based prioritization: A conventional model can score the same vulnerability much faster from structured inputs such as CVSS metrics, vulnerability age, vendor information, and available enrichment metadata. This works well when the relevant signals are already encoded as features. The difficulty is that some of the most useful signals arrive as text or emerge after disclosure. The quality of a new PoC, evidence of active targeting, changes in attacker behavior, or deployment-specific constraints may never appear in the feature vector. Missing patch or exploit metadata can further weaken the score. The model can therefore rank the vulnerability quickly while still missing changes that make the threat more urgent in practice. Polar prioritization: Polar processes the same incident together with the surrounding cyber evidence. It collects the advisory, CTI reports, public PoCs, exploitation reports, and other source-linked observations, then organizes them into a temporal sequence such as disclosure→PoC→KEV→in-the-wild exploitationdisclosure -the-wild exploitation. The model examines how quickly these events occur, whether the PoC is readily weaponizable, and whether current attacker activity matches the affected environment. From this evidence, Polar estimates the probability of exploitation within the next 30 days and combines that assessment with the threat’s technical severity. It then links the prioritized threat to applicable mitigation evidence, such as vendor patches, workarounds, and defensive controls. This example illustrates the key design principle of Polar: cyber prioritization depends on evidence that changes over time and arrives in different forms. A useful system must keep those signals connected to the threat being assessed and carry them through to the mitigation decision. 3 Polar: Real-World Cyber Evidence Synthesis Algorithm 1 Cyber Evidence Synthesis Input: Incidents ℐ=ijj=1NI=\i_j\_j=1^N; evidence sources D Output: Evidence =zkk=1MZ=\z_k\_k=1^M // Disentangle threat instances foreach ij∈ℐi_j do j←ϕLLM(ij)=τj,1,…,τj,LjT_j← _LLM(i_j)=\ _j,1,…, _j,L_j\; end foreach // Ground threats in external evidence foreach τk∈⋃j _k∈ _jT_j do ℰk←ψ⁡(τk,)E_k←ψ( _k,D); k←Metadata(τk,)m_k← Metadata( _k,D); zk←(τk,k,ℰk)z_k←( _k,m_k,E_k); end foreach return =zkk=1MZ=\z_k\_k=1^M; Polar synthesizes heterogeneous cyber reports into threat-centric evidence for downstream security analysis. Figure 2 illustrates the workflow. Below we detail the design of Polar. 3.1 Real-World Cyber Evidence Synthesis Cyber evidence is distributed across reports that differ in scope, structure, and timing. A vendor advisory may describe several vulnerabilities together, while exploit repositories and later threat reports contribute new information about weaponization and deployment conditions. We formulate evidence synthesis as the construction of a structured representation (Algorithm 1) centered on an individual threat while retaining the provenance and temporal context of its supporting evidence. ❶Threat disentanglement. Let ℐ=i1,…,iNI=\i_1,…,i_N\ denote the raw incidents available at analysis time t. An incident may describe several vulnerabilities, campaigns, or related indicators. Polar applies an LLM-based separation operator ϕLLM _LLM to obtain canonical threat instances τk _k, while preserving the affected component, exploitation path, and deployment conditions associated with each instance. This separation reduces evidence conflation when multiple threats appear in the same report. Detailed instructions are provided in Appendix D.1. ❷Source-aware evidence enrichment. For each threat τk _k, Polar retrieves complementary evidence from external sources D, including vulnerability databases, ATT&CK knowledge, exploitation feeds, and vendor or government advisories. The resulting set ℰk=ψ⁡(τk,)=ek,1,…,ek,RkE_k=ψ( _k,D)=\e_k,1,…,e_k,R_k\ contains evidence units ek,r=(sk,r,uk,r,tk,r,ck,r)e_k,r=(s_k,r,u_k,r,t_k,r,c_k,r), where sk,rs_k,r denotes the supporting content, uk,ru_k,r as its source, tk,rt_k,r as its timestamp when available, and ck,rc_k,r as its analytical role. In parallel, Polar extracts standardized metadata km_k, including the CVE identifier, affected product, disclosure date, and ATT&CK mappings. Together they form the threat-centric evidence zk=(τk,k,ℰk)z_k=( _k,m_k,E_k). Figure 2: Overview of Polar. Real-world cyber evidence is synthesized into structured threat profiles that support downstream threat prioritization and mitigation recommendation. Note that zkz_k includes severity and temporal evidence, thus facilitating subsequent CVSS assessment and exploitation analysis. Given an analytical query q (i.e., a task), Polar selects the corresponding view ℰk(q)⊆ℰkE_k^(q) _k for task-specific analysis while retaining provenance and contextual dependencies. Example 1: Synthesizing evidence for a Print Spooler threat Raw incident iji_j: A Windows 11 report states that an authenticated remote attacker can abuse the Print Spooler through a crafted DCERPC request to load a DLL and execute code as NT AUTHORITY. Threat instance τk _k: Polar disentangles this report into a canonical Print Spooler threat, preserving its affected component, remote exploitation path, and privilege conditions. Evidence profile zkz_k: Polar extracts metadata km_k (e.g., the mapped CVE, affected versions, and ATT&CK techniques), and constructs ℰkE_k from source-linked evidence units ek,r=(sk,r,uk,r,tk,r,ck,r)e_k,r=(s_k,r,u_k,r,t_k,r,c_k,r). For example, “authenticated remote attacker” is retained as severity evidence, while a CISA KEV record contributes temporally grounded exploitation evidence. Applying this procedure to all incidents yields =z1,…,zMZ=\z_1,…,z_M\, which is shared by the two applications below. 3.2 Application I: Cyber Threat Prioritization Threat prioritization combines two complementary assessments. The severity score sks_k captures the technical consequences and exploitation conditions of a vulnerability, while the exploitation probability pkp_k reflects its evolving likelihood of real-world exploitation. Keeping both quantities explicit allows threats with similar static severity to be distinguished according to current threat dynamics. Algorithm 2 summarizes how Polar derives these two assessments from zkz_k and combines them into the final priority ordering. Algorithm 2 Threat Prioritization Input: Evidence set Z; CVSS guidance DCVSSD_CVSS Output: Priority ordering πpri _pri foreach zk∈z_k do foreach CVSS metric i do ℰk(i)←Select(ℰk,i)E_k^(i)← Select(E_k,i); vk(i)←fLLM(i)(ℰk(i),DCVSS)v_k^(i)← f_LLM^(i)(E_k^(i),D_CVSS); end foreach sk←CVSS(k)s_k _CVSS(v_k); ℰktemp←TemporalView(ℰk)E_k^temp← TemporalView(E_k); pk←fLLMexp(zk,k,ℰktemp)p_k← f_LLM^exp(z_k,v_k,E_k^temp); rk←(zk,sk,pk)r_k←(z_k,s_k,p_k); end foreach πpri←Rank(rkk=1M) _pri← Rank(\r_k\_k=1^M); return πpri _pri; ❶Evidence-grounded severity assessment. We represent technical severity through the CVSS vector k=(vk(1),…,vk(d))∈(1)×⋯×(d)v_k=(v_k^(1),…,v_k^(d)) ^(1)×·s×Y^(d), where (i)Y^(i) is the valid categorical domain of metric i. For each metric, Polar selects a source-linked evidence view ℰk(i)⊆ℰkE_k^(i) _k and predicts vk(i)=fLLM(i)(ℰk(i),DCVSS)v_k^(i)=f_LLM^(i)(E_k^(i),D_CVSS) under the official CVSS instructions (FIRST, 2019a; FIRST, 2019b). Exposure evidence informs Attack Vector, exploitation preconditions inform Attack Complexity, authentication requirements inform Privileges Required, and victim-action dependencies inform User Interaction. Confidentiality, integrity, and availability are inferred from evidence describing the consequences of successful exploitation. Detailed metric-specific workflows are provided in Appendix D.2.1. Once all categorical metrics are determined, the official scoring function computes sk=CVSS(k)s_k=S_CVSS(v_k), with sk∈[0,10]s_k∈[0,10]. The LLM thus interprets the source-linked evidence required by each CVSS dimension, while the standardized scoring procedure performs numerical aggregation. Example 2: Evidence-grounded Attack Vector assessment For the threat in Example 1, Polar selects the source spans “authenticated remote attacker” and “crafted DCERPC request”, together with protocol evidence indicating RPC over SMB/DCERPC. When local and remote cues coexist, the model checks which access mode is supported by the documented exploitation path. The resulting evidence supports AV=Network. The remaining CVSS metrics are assessed independently before the official scoring procedure computes sks_k. ❷Temporal exploitation assessment. Static severity is complemented by a temporally ordered evidence view ℰktemp=(tℓ,eℓ,uℓ)ℓ=1LkE_k^temp=\(t_ ,e_ ,u_ )\_ =1^L_k, where each tuple records an exploitation-related observation, its timestamp, and its source. Such observations include vulnerability disclosure, public PoC release, Exploit-DB publication, CISA KEV listing, malware observations, and reports of exploitation in the wild. Polar orders these events chronologically and preserves their temporal gaps, yielding trajectories such as disclosure→PoC→KEV→in-the-wild exploitationdisclosure -the-wild exploitation. Conditioned on the threat evidence zkz_k, its CVSS representation kv_k, and the temporal evidence ℰktempE_k^temp, Polar estimates pk=fLLMexp(zk,k,ℰktemp)p_k=f_LLM^exp(z_k,v_k,E_k^temp), where pk∈[0,1]p_k∈[0,1] denotes the probability of observed exploitation within the next 30 days, following the prediction horizon used by EPSS (Jacobs et al., 2021b; Jacobs et al., 2021a). The complete set of exploitation sources is described in Appendix D.2.2. ❸Joint prioritization. The resulting rk=(zk,sk,pk)r_k=(z_k,s_k,p_k) couples synthesized evidence with standardized severity and dynamic exploitation likelihood. Given concurrent threats, Polar compares the resulting rkr_k to produce the priority ordering πpri _pri. The explicit intermediate quantities also expose the severity and exploitation evidence underlying the final ranking. 3.3 Application I: Evidence-Grounded Mitigation Recommendation Algorithm 3 Mitigation Synthesis Input: Evidence set rkk=1M\r_k\_k=1^M; remediation corpus remD_rem Output: Mitigation plan Πmit _mit foreach rk=(zk,sk,pk)r_k=(z_k,s_k,p_k) do // Retrieve candidate actions k←fLLMret(zk,rem)A_k← f_LLM^ret(z_k,D_rem); // Normalize and verify applicability k←Normalize(k)A_k← Normalize(A_k); k←FilterApplicable(k,zk)A_k← FilterApplicable(A_k,z_k); end foreach // Synthesize ordered mitigation actions Πmit←fLLMmit((rk,k)k=1M) _mit← f_LLM^mit(\(r_k,A_k)\_k=1^M); return Πmit _mit; Mitigation translates the synthesized threat assessment into concrete defensive actions. Algorithm 3 summarizes this process from remediation retrieval to the final mitigation ordering. Given zkz_k, Polar retrieves candidate mitigations from an authoritative remediation corpus remD_rem containing vendor security bulletins, NVD references, CISA KEV notes, and MITRE ATT&CK mitigations. This produces k=fLLMret(zk,rem)=ak,1,…,ak,JkA_k=f_LLM^ret(z_k,D_rem)=\a_k,1,…,a_k,J_k\, with each action linked to its supporting source. We organize the retrieved evidence into the four categories used in our evaluation: CVE-to-patch mappings, ATT&CK-aligned mitigations, mitigation notes or workarounds, and vendor advisories. ❶Applicability grounding. Candidate actions are matched against the synthesized threat context before recommendation. Product and version metadata determine patch applicability, exploitation-path evidence identifies relevant compensating controls, and temporal evidence distinguishes current guidance from superseded remediation. Polar also normalizes semantically overlapping actions while retaining their supporting provenance, producing a threat-specific action set kA_k. ❷Mitigation ordering. Given the prioritized rk\r_k\ and associated candidate actions k\A_k\, Polar produces Πmit=fLLMmit((rk,k)k=1M) _mit=f_LLM^mit(\(r_k,A_k)\_k=1^M). The ordering considers threat severity and exploitation likelihood together with mitigation-specific factors such as patch availability, workaround effectiveness, implementation complexity, and operational disruption. The synthesized evidence therefore connects the evidence establishing threat urgency with the evidence supporting an appropriate defensive response. Output. Polar returns the priority ordering πpri _pri together with the source-linked mitigation plan Πmit _mit. Both applications operate on the same threat-centric evidence: prioritization maps evidence to urgency, while mitigation maps the resulting assessment to actionable defense. 4 Experiment We perform extensive evaluations on Polar, aiming to answer the following research questions: RQ1: How effective is Polar in threat prioritization and mitigation recommendation compared with existing baselines? RQ2: How does each component of Polar contribute to its overall performance? RQ3: How does Polar perform across individual pipeline stages? RQ4: Can Polar generalize to zero-day vulnerability analysis? LLMs. As baseline and backbone of Polar, we evaluate with five representative LLMs: Gemini-3.1-Pro (GE3.1), GPT-5 (G5), LLaMA-3-70B-Instruct (L70B), Claude Opus 4.1 (C4.1), and Qwen3-30B-A3B-Instruct-2507 (Q3). We also evaluate three LLM-based cybersecurity-specialist agents: Foundation-Sec-8B-Instruct (FS) (Singer, 2025), Lily-Cybersecurity-7B (LY) (Labs, 2024), and ZySec-7B (ZY) (ZySec AI, 2024). Data. We collect raw threat incidents from high-fidelity vendor advisories (e.g., Microsoft, Cisco, Oracle), security reports (e.g., Mandiant (Mandiant, 2004)), public CTI aggregators (e.g., the KEV Catalog (Cybersecurity and Infrastructure Security Agency (CISA), 2024)), and exploit repositories (e.g., Exploit-DB (Offensive Security, 2025) and GitHub PoCs). Each incident is converted into structured evaluations covering four stages of Polar: (i) triage and metadata enrichment grounded in authoritative repositories such as CVE/NVD (CVE Program, 2024) and MITRE ATT&CK (Strom et al., 2018); (i) CVSS assessment validated against official NVD vectors; (i) exploitation likelihood referenced from the FIRST.org EPSS dataset (Jacobs et al., 2021b); and (iv) mitigation strategies collected from NVD references, KEV mitigation notes, and vendor security updates. We standardize incidents into stage-specific tasks and use official repository assignments as reference answers when ambiguity arises. Dataset statistics and quality-control procedures are reported in Appendix E.1. Baselines. We compare Polar with representative non-LLM and LLM-based methods for vulnerability analysis and mitigation mapping. For threat prioritization, we include CVSS-BERT (Shahid and Debar, 2021), which predicts CVSS vectors from vulnerability descriptions using fine-tuned BERT classifiers, and DeepCVA (Le et al., 2021), which jointly predicts CVSS metrics with multi-task deep learning. Both obtain severity scores using the official CVSS formula. For mitigation recommendation, we use CVE2CAPEC11 1 https://github.com/Galeax/CVE2CAPEC, a rule-based system that maps CVEs to CWEs and CAPEC attack patterns, and V2W-BERT (Das et al., 2021), which predicts CWE categories from CVE descriptions and retrieves associated mitigations from CWE definitions. We also include two recent LLM-based cyber analysis frameworks as end-to-end baselines. AutoCVSS (Sanvito et al., 2025) prompts LLMs to predict CVSS vectors and derives threat rankings from the resulting severity scores. TRIAGE (Høst et al., 2025) maps CVEs to MITRE ATT&CK techniques using rule-based prompting and in-context learning; we then retrieve the corresponding official ATT&CK mitigations for evaluation. Since these systems have their own complete pipelines, Polar is evaluated against them directly rather than layered on top. CVSS- and EPSS-based rankings serve as reference signals in our evaluation and are therefore not treated as baselines. 4.1 Main Results: Threat Prioritization and Mitigation Recommendation (RQ1) Setting. We focus on the two most decision-critical outcomes in operational CTI workflows: (1) threat prioritization, evaluated by ranking-based metrics (NDCG@5 and Kendall’s τ) against reference urgency order, and (2) mitigation recommendation, evaluated by the F1 score between generated mitigation items and database-sourced references. We compare Polar against backbone general-purpose LLMs, cybersecurity-specialist agents, and representative non-LLM baselines. We also compare Polar with recent LLM-based cyber analysis frameworks. Table 1: Evaluation of threat prioritization and mitigation recommendation (mean± across five runs). Ranking quality is measured by NDCG@5 and Kendall’s τ, and mitigation retrieval is evaluated by F1 against reference mitigation items. “N/A” represents the baseline is not capable for corresponding tasks. All results are the mean and standard deviation over five runs. All metrics except Kendall’s τ are reported in percentage (%). Model Prioritization Correctness Mitigation Retrieval NDCG@5 Kendall’s τ CVE-to-Patch ATT&CK Mapping Mitigation Note Vendor Advisory Non-LLM heuristic baseline CVSS-BERT 51.2 ± 0.5 0.361 ± 0.012 N/A N/A N/A N/A DeepCVA 55.7 ± 0.4 0.404 ± 0.010 N/A N/A N/A N/A CVE2CAPEC N/A N/A 29.8 ± 0.9 N/A 24.1 ± 1.5 26.8 ± 0.6 V2W-BERT N/A N/A 33.6 ± 0.6 N/A 28.7 ± 1.1 30.9 ± 0.7 LLM-based cyber analysis framework AutoCVSS 59.8 ± 1.2 0.447 ± 0.007 N/A N/A N/A N/A TRIAGE N/A N/A N/A 54.2 ± 1.2 N/A N/A Cybersecurity-specialized agent Polar + FS 68.5 ± 0.8 (↑ 8.3) 0.553 ± 0.009 (↑ 0.101) 73.4 ± 1.3 (↑ 11.3) 63.5 ± 1.5 (↑ 13.2) 69.3 ± 1.4 (↑ 9.1) 62.5 ± 0.9 (↑ 7.3) LY 69.4 ± 0.7 (↑ 9.2) 0.564 ± 0.016 (↑ 0.112) 71.7 ± 0.8 (↑ 9.6) 62.4 ± 0.8 (↑ 12.1) 68.3 ± 0.7 (↑ 8.1) 61.6 ± 0.9 (↑ 6.4) ZY 70.5 ± 0.6 (↑ 10.3) 0.575 ± 0.016 (↑ 0.123) 74.2 ± 0.8 (↑ 12.1) 64.6 ± 1.3 (↑ 14.3) 70.4 ± 0.8 (↑ 10.2) 63.4 ± 1.4 (↑ 8.2) General-purpose LLM Polar + GE3.1 85.8 ± 1.3 (↑ 24.9) 0.768 ± 0.017 (↑ 0.309) 92.7 ± 1.4 (↑ 30.1) 80.9 ± 0.5 (↑ 29.8) 89.1 ± 1.0 (↑ 28.8) 81.5 ± 1.0 (↑ 26.2) G5 87.3 ± 0.7 (↑ 27.1) 0.783 ± 0.019 (↑ 0.331) 94.3 ± 0.9 (↑ 32.2) 81.5 ± 1.1 (↑ 31.2) 90.3 ± 1.3 (↑ 30.1) 82.3 ± 0.7 (↑ 27.1) L70B 76.5 ± 0.5 (↑ 16.3) 0.673 ± 0.016 (↑ 0.221) 82.4 ± 1.1 (↑ 20.3) 74.4 ± 1.3 (↑ 24.1) 81.4 ± 1.0 (↑ 21.2) 73.5 ± 0.5 (↑ 18.3) C4.1 83.4 ± 0.7 (↑ 23.2) 0.743 ± 0.006 (↑ 0.291) 90.4 ± 0.8 (↑ 28.3) 80.4 ± 1.2 (↑ 30.1) 88.4 ± 1.0 (↑ 28.2) 80.5 ± 0.5 (↑ 25.3) Q3 80.6 ± 0.4 (↑ 20.4) 0.714 ± 0.014 (↑ 0.262) 87.2 ± 1.1 (↑ 25.1) 77.4 ± 0.8 (↑ 27.1) 86.3 ± 0.4 (↑ 26.1) 78.5 ± 0.4 (↑ 23.3) Polar consistently outperforms non-LLM baselines on both prioritization and mitigation. Table 1 shows that severity-only predictors (e.g., CVSS-BERT, DeepCVA) provide limited prioritization accuracy, as they rely solely on predicted CVSS scores without considering exploitation likelihood or contextual threat intelligence. In contrast, Polar significantly improves both NDCG@5 and Kendall’s τ by jointly reasoning over severity (sk)(s_k), exploitation likelihood (pk)(p_k), and enriched CTI evidence. For mitigation recommendation, heuristic approaches like CVE2CAPEC achieve low F1 scores due to their reliance on predefined linkage rules that fail to capture nuanced contextual relationships. Similarly, V2W-BERT is limited by its single-source knowledge dependency on CWE definitions, which often provide generic rather than actionable mitigations. Polar consistently surpasses these baselines, particularly on mitigation notes and vendor advisories that require contextual reasoning beyond pattern matching. 4.2 Ablation Study (RQ2) Setting. To understand the contribution of individual components in Polar, we conduct an ablation study by selectively removing one stage from the pipeline at a time. We evaluate three representative backbone models: Gemini-3.1-Pro (GE3.1), GPT-5 (G5), and LLaMA-3-70B-Instruct (L70B). For each backbone, we consider the following ablations: (i) w/o Triage, which removes incident disentanglement and metadata grounding; (i) w/o Static Analysis, which bypasses structured CVSS reasoning; and (i) w/o Exploitation Analysis, which excludes exploitation likelihood modeling. All variants are evaluated using the same metrics as in the main experiment. Table 2: Ablation results on prioritization and mitigation (mean± across five runs). Each block uses a different backbone model and reports the performance of the full Polar pipeline and variants with one component removed. Results are reported as mean ± standard deviation over five runs. All metrics except Kendall’s τ are reported in percentage (%). Variant Prioritization Correctness Mitigation Retrieval NDCG@5 Kendall’s τ CVE-to-Patch ATT&CK Mapping Mitigation Note Vendor Advisory Gemini-3.1-Pro (GE3.1) Full Polar 85.8 ± 1.2 0.768 ± 0.014 92.7 ± 1.0 80.9 ± 1.0 89.1 ± 1.4 81.5 ± 1.0 w/o Triage 78.6 ± 1.4 0.679 ± 0.011 84.6 ± 0.6 73.4 ± 1.0 80.9 ± 0.7 74.2 ± 0.4 w/o Static Analysis 81.1 ± 1.2 0.704 ± 0.009 86.8 ± 1.2 75.5 ± 1.1 83.4 ± 0.6 76.8 ± 0.8 w/o Exploit. Analysis 82.4 ± 1.2 0.718 ± 0.009 87.7 ± 1.3 76.7 ± 0.8 84.9 ± 0.9 78.1 ± 1.2 GPT-5 (G5) Full Polar 87.3 ± 0.9 0.783 ± 0.019 94.3 ± 1.6 81.5 ± 1.3 90.3 ± 0.9 82.3 ± 1.5 w/o Triage 80.1 ± 0.7 0.693 ± 0.013 86.2 ± 0.9 74.2 ± 1.2 82.1 ± 1.4 75.1 ± 1.3 w/o Static Analysis 82.4 ± 1.0 0.718 ± 0.014 88.3 ± 1.4 76.1 ± 1.4 84.6 ± 0.6 77.6 ± 1.1 w/o Exploit. Analysis 83.8 ± 0.6 0.732 ± 0.011 89.1 ± 1.1 77.4 ± 1.1 86.1 ± 0.7 78.9 ± 0.8 LLaMA-3-70B (L70B) Full Polar 76.5 ± 0.7 0.673 ± 0.017 82.4 ± 0.5 74.4 ± 0.7 81.4 ± 0.5 73.5 ± 1.0 w/o Triage 73.2 ± 1.3 0.624 ± 0.008 78.1 ± 0.9 69.1 ± 1.1 75.4 ± 0.8 68.3 ± 1.4 w/o Static Analysis 75.4 ± 1.0 0.648 ± 0.008 80.2 ± 0.5 70.9 ± 1.6 77.6 ± 0.7 70.1 ± 0.5 w/o Exploit. Analysis 76.8 ± 0.6 0.662 ± 0.011 81.1 ± 1.1 72.1 ± 1.2 78.9 ± 0.6 71.4 ± 1.1 All components contribute to the overall effectiveness of Polar. Table 2 shows that removing any single stage leads to consistent degradation across both prioritization and mitigation metrics. Among the three components, triage removal causes the largest performance drop, particularly in prioritization accuracy, highlighting the importance of disentangling raw incidents and grounding them in authoritative metadata. Excluding static analysis primarily affects severity-sensitive ranking and patch alignment, while removing exploitation analysis has a more pronounced impact on mitigation ordering when multiple medium-severity threats compete. These results indicate that Polar’s performance gains arise from the joint interaction of its components. 4.3 Breakdown Analysis Across Pipeline Stages (RQ3) We analyze Polar by breaking down its performance across individual pipeline stages: CTI triage, static analysis, and exploitation forecasting. This analysis contextualizes the gains observed in the main experiment (RQ1) and ablation study (RQ2), and highlights how each stage contributes to the overall effectiveness of the system. CTI triage establishes a reliable foundation for downstream reasoning. Across evaluated LLM backbones, Polar consistently improves incident disentanglement and metadata enrichment, especially for entangled advisories and knowledge-grounded attributes such as ATT&CK techniques and exploitation status. By converting unstructured CTI into structured, aligned representations, the triage stage reduces ambiguity in downstream reasoning and mitigates error propagation to later stages. Static analysis benefits from evidence-grounded reasoning. Figure 3 shows that Polar improves classification accuracy across all eight CVSS base metrics, with particularly notable gains on context-dependent dimensions such as Attack Vector and Attack Complexity. These improvements indicate that combining retrieval-grounded evidence from CTI triage with structured reasoning enables more reliable interpretation of vulnerability descriptions than severity-only prediction. Figure 3: Static analysis performance (per-metric accuracy) across baseline models and Polar. In addition to per-metric accuracy, Polar also reduces overall severity scoring error, as reflected by consistently lower RMSE in Figure 4. This indicates that improvements are not limited to isolated CVSS fields, but translate into more reliable aggregate severity assessments that directly support prioritization decisions. Exploitation analysis enhances robustness under dynamic threat conditions. For exploitation forecasting, Polar shows improved robustness across different exploitation trends and historical context windows. While baseline models can track gradual changes, Polar better adapts to abrupt shifts by linking temporal signals to broader threat narratives, which is critical when new exploits or proof-of-concept releases rapidly alter risk profiles. Overall, the breakdown analysis demonstrates that Polar ’s performance gains arise from the complementary interaction of its pipeline stages rather than improvements isolated to any single component. Detailed quantitative results, additional figures, and per-stage analyses are provided in Appendix E.2.1, Appendix E.2.4, and Appendix E.2.5. 4.4 Additional Experiments (RQ4) We further evaluate Polar on zero-day vulnerabilities to assess its generalization beyond disclosed and well-documented threats. This setting focuses on vulnerabilities that lack complete metadata or official CVE annotations at the time of analysis, reflecting realistic early-stage threat assessment scenarios. Due to space limitations, we defer detailed analyses to the appendix: zero-day experiments (Appendix E.2.3), breakdown analysis with quantitative results for individual pipeline stages (Appendix E.2.1, E.2.4, E.2.5), and dataset statistics (Appendix E.1). 5 Related Work Threat prioritization. Traditional approaches to threat prioritization primarily relied on heuristic-driven models. Statistical and probabilistic methods, including Bayesian models and attack graphs, have been used to assess risk propagation and exploit likelihood within specific infrastructures (Ingols et al., 2009; Poolsappasit et al., 2012). Other approaches integrate expert knowledge with structured taxonomies, such as MITRE’s ATT&CK framework, to map observed adversary techniques to potential system impacts (Strom et al., 2018). However, these methods generally emphasize static attributes and predefined rules, making them less effective in rapidly evolving threat environments. LLMs for cybersecurity tasks. Surveys report broad LLM capability in code analysis, vuln detection/repair, and broader security workflows (Gwak et al., 2026; Hasanov et al., 2024; Das et al., 2025; Zhou et al., 2025; Chen et al., 2025). Task-specific systems show gains in penetration testing via tool use and chain-of-thought orchestration (Deng et al., 2024; Desai et al., 2026), and in attack modeling via retrieval-augmented generation over threat knowledge bases (Prapty et al., 2024; Meng et al., 2025b; Meng et al., 2025a). Evaluation and deployment studies surface challenges around robustness, hallucination, and operational risk (Liu et al., 2025; McGraw et al., 2024; Keppler et al., 2024). Most prior efforts, however, target isolated tasks rather than end-to-end prioritization. LLM agents and automation. LLM-as-agent paradigms combine reasoning, tools, and environment interaction for complex goals (More et al., 2026; Vijayaraghavan et al., 2026; Lu et al., 2025; Meng et al., 2026; Dong et al., 2023). In security, automated attack-graph construction and reasoning trace feasible paths and preconditions (Ou et al., 2005; Sheyner et al., 2002), while multi-agent designs specialize roles across assessment, exploitation prediction, and mitigation planning (Sancho et al., 2020). Retrieval-augmented agents and deep log-analysis models enhance detection under real-world data heterogeneity (Du et al., 2017; Zhang et al., 2022; Uetz et al., 2024). 6 Conclusion We present Polar, an LLM-powered framework for synthesizing real-world cyber evidence for threat prioritization and mitigation. Polar organizes heterogeneous evidence into threat-centric representations, combines severity with temporal exploitation signals for prioritization, and connects the resulting assessments to source-linked mitigation actions. Our experiments show consistent improvements across prioritization and mitigation tasks, including heterogeneous and zero-day settings. These results demonstrate the value of evidence synthesis for practical LLM-based cyber decision support. References Almutairi (2026) N. Almutairi LLM-powered proactive cyber-defense framework using cyber-threat indicators collected from x platform. Electronics 15 (6), p. 1305. Cited by: §1. Bahlibi et al. (2026) K. Bahlibi, H. L. Nguyen, E. Dogdu, R. Choupani, and W. Mitchell Beyond single-hop: link prediction through multi-hop reasoning in malware knowledge graphs. In 2026 IEEE 5th International Conference on AI in Cybersecurity (ICAIC), p. 1–10. Cited by: §1. Barr-Smith et al. (2021) F. Barr-Smith, X. Ugarte-Pedrero, M. Graziano, R. Spolaor, and I. Martinovic Survivalism: systematic analysis of windows malware living-off-the-land. In 2021 IEEE Symposium on Security and Privacy (SP), p. 1557–1574. Cited by: §1. Chen et al. (2025) Y. Chen, W. Sun, C. Fang, Z. Chen, Y. Ge, T. Han, Q. Zhang, Y. Liu, Z. Chen, and B. Xu Security of language models for code: a systematic literature review. ACM Transactions on Software Engineering and Methodology. Cited by: §5. Computer Emergency Response Team Coordination Center (CERT/C) (1988) Computer Emergency Response Team Coordination Center (CERT/C) CERT security bulletins. Note: https://w.cert.org/ Cited by: 4th item, §E.1. CVE Program (2024) CVE Program Common vulnerabilities and exposures (cve). Note: https://w.cve.org/ Cited by: 1st item, §4. Cybersecurity and Infrastructure Security Agency (CISA) (2024) Cybersecurity and Infrastructure Security Agency (CISA) Known exploited vulnerabilities catalog. Note: https://w.cisa.gov/known-exploited-vulnerabilities-catalog Cited by: 3rd item, 2nd item, §E.1, §1, §4. Das et al. (2025) B. C. Das, M. H. Amini, and Y. Wu Security and privacy challenges of large language models: a survey. ACM Computing Surveys 57 (6), p. 1–39. Cited by: §5. Das et al. (2021) S. S. Das, E. Serra, M. Halappanavar, A. Pothen, and E. Al-Shaer V2w-bert: a framework for effective hierarchical multiclass classification of software vulnerabilities. In 2021 IEEE 8th International Conference on Data Science and Advanced Analytics (DSAA), p. 1–12. Cited by: §4. Deng et al. (2024) G. Deng, Y. Liu, V. Mayoral-Vilches, P. Liu, Y. Li, Y. Xu, T. Zhang, Y. Liu, M. Pinzger, and S. Rass \pentestgpt\: Evaluating and harnessing large language models for automated penetration testing. In 33rd USENIX Security Symposium (USENIX Security 24), p. 847–864. Cited by: §1, §5. Desai et al. (2026) P. Desai, L. Tang, Y. Meng, and Z. Xi Safegpt: preventing data leakage and unethical outputs in enterprise llm use. arXiv preprint arXiv:2601.06366. Cited by: §5. Dong et al. (2023) F. Dong, L. Wang, X. Nie, F. Shao, H. Wang, D. Li, X. Luo, and X. Xiao \distdet\: A \cost-effective\ distributed cyber threat detection system. In 32nd USENIX Security Symposium (USENIX Security 23), p. 6575–6592. Cited by: §1, §5. Du et al. (2017) M. Du, F. Li, G. Zheng, and V. Srikumar Deeplog: anomaly detection and diagnosis from system logs through deep learning. In Proceedings of the 2017 ACM SIGSAC conference on computer and communications security, p. 1285–1298. Cited by: §5. Eling et al. (2023) M. Eling, R. Ibragimov, and D. Ning Time dynamics of cyber risk. Available at SSRN 4497621. Cited by: §1. FIRST (2019a) FIRST Common vulnerability scoring system version 3.1 specification document (revision 1). Note: https://w.first.org/cvss/v3-1/cvss-v31-specification_r1.pdf Cited by: §1, §3.2. FIRST (2019b) FIRST CVSS v3.1 user guide. Note: https://w.first.org/cvss/v3-1/user-guide Cited by: §1, §3.2. Gwak et al. (2026) J. Gwak, A. Strier, Z. Xi, G. Yan, X. Shu, S. D. Stoller, and P. Yang LADE: llm-assisted advanced persistent threat detection and explanation. In International Conference on Security and Privacy in Communication Systems, p. 245–273. Cited by: §5. Hasanov et al. (2024) I. Hasanov, S. Virtanen, A. Hakkala, and J. Isoaho Application of large language models in cybersecurity: a systematic literature review. IEEE Access. Cited by: §5. Høst et al. (2025) A. M. Høst, P. Lison, and L. Moonen A systematic approach to predict the impact of cybersecurity vulnerabilities using llms. In 2025 IEEE 24th International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom), p. 1598–1607. Cited by: §4. Ingols et al. (2009) K. Ingols, R. Chu, R. Lippmann, S. Webster, and S. Boyer Model-based analysis of configuration vulnerabilities. In Proceedings of the 2009 Workshop on Cyber Security Experimentation and Test, p. 1–6. Cited by: §5. Jacobs et al. (2021a) J. Jacobs, S. Romanosky, B. Edwards, I. Adjerid, and M. Roytman Exploit prediction scoring system (epss). Digital Threats: Research and Practice 2 (3), p. 1–17. Cited by: §3.2. Jacobs et al. (2019) J. Jacobs, S. Romanosky, B. Edwards, M. Roytman, and I. Adjerid Exploit prediction scoring system (epss). Note: https://arxiv.org/abs/1908.04856 Cited by: §1. Jacobs et al. (2021b) J. Jacobs, S. Romanosky, B. Edwards, M. Roytman, and I. Adjerid Exploit prediction scoring system (epss). ACM Digital Threats: Research and Practice. External Links: Document Cited by: §1, §3.2, §4. Jørgensen and Ma (2026) B. N. Jørgensen and Z. G. Ma Cybersecurity and resilience of smart grids: a review of threat landscape, incidents, and emerging solutions. Applied Sciences 16 (2), p. 981. Cited by: §1. Keppler et al. (2024) G. Keppler, J. Kunz, V. Hagenmeyer, and G. Elbez Evaluating large language models in cybersecurity knowledge with cisco certificates. In Nordic Conference on Secure IT Systems, p. 219–238. Cited by: §5. Labs (2024) S. L. Labs Lily-cybersecurity-7b-v0.2. Note: Model on Hugging Face Cited by: §4. Le et al. (2021) T. H. M. Le, D. Hin, R. Croft, and M. A. Babar Deepcva: automated commit-level vulnerability assessment with deep multi-task learning. In 2021 36th IEEE/ACM International Conference on Automated Software Engineering (ASE), p. 717–729. Cited by: §4. Liu et al. (2024) S. Liu, G. Peng, H. Zeng, and J. Fu A survey on the evolution of fileless attacks and detection techniques. Computers & Security 137, p. 103653. Cited by: §1. Liu et al. (2025) X. Liu, J. Liang, Q. Yan, J. Jang, S. Mao, M. Ye, J. Jia, and Z. Xi CyLens: towards reinventing cyber threat intelligence in the paradigm of agentic large language models. arXiv preprint arXiv:2502.20791. Cited by: §5. Lu et al. (2025) Y. Lu, L. Li, D. Zhang, X. Jian, T. Wang, S. Chen, Y. Lei, J. Tong, Z. Xi, H. Chu, et al. Empowering clinical trial design through ai: a randomized evaluation of powergpt. arXiv preprint arXiv:2509.12471. Cited by: §5. Mandiant (2004) Mandiant Mandiant. Note: https://w.mandiant.com/ Cited by: §4. McGraw et al. (2024) G. McGraw, R. Bonett, H. Figueroa, and K. McMahon 23 security risks in black-box large language model foundation models. Computer 57 (4), p. 160–164. Cited by: §5. Meng et al. (2025a) Y. Meng, L. Tang, F. Yu, J. Jia, G. Yan, P. Yang, and Z. Xi Uncovering vulnerabilities of llm-assisted cyber threat intelligence. arXiv preprint arXiv:2509.23573. Cited by: §1, §5. Meng et al. (2025b) Y. Meng, L. Tang, F. Yu, X. Li, G. Yan, P. Yang, and Z. Xi Benchmarking llm-assisted blue teaming via standardized threat hunting. arXiv preprint arXiv:2509.23571. Cited by: §1, §5. Meng et al. (2026) Y. Meng, L. Tang, D. Zhang, R. Brens, E. J. Romero, N. Guo, S. Elkefi, and Z. Xi Small agent group is the future of digital health. arXiv preprint arXiv:2602.08013. Cited by: §5. More et al. (2026) V. More, L. Lu, Z. Ding, Z. Xi, S. Mizia, and N. L. Guo TheraMind: a multi-llm ensemble for accelerating drug repurposing in lung cancer via case report mining. npj Precision Oncology 10 (1), p. 95. Cited by: §5. Nguyen et al. (2026) T. H. Nguyen, C. Pruski, and M. D. Silveira Deepening citation understanding in scientific literature via llm-powered context extraction. Scientometrics, p. 1–32. Cited by: §1. Offensive Security (2025) Offensive Security Exploit Database (Exploit-DB). Note: https://w.exploit-db.com/ Cited by: 4th item, 1st item, §E.1, §1, §4. Ou et al. (2005) X. Ou, S. Govindavajhala, A. W. Appel, et al. MulVAL: a logic-based network security analyzer.. In USENIX security symposium, Cited by: §5. Pakshad et al. (2026) P. Pakshad, M. Dawson, E. Hoxha, and A. H. Khan LLM-based analysis for discovering cybersecurity patterns in public administration cyber events. In International conference KNOWLEDGE-BASED ORGANIZATION, Vol. 32, p. 1–10. Cited by: §1. Poolsappasit et al. (2012) N. Poolsappasit, R. Dewri, and I. Ray Dynamic security risk management using bayesian attack graphs. IEEE Transactions on Dependable and Secure Computing 9 (1), p. 61–74. Cited by: §5. Prapty et al. (2024) R. T. Prapty, A. Kundu, and A. Iyengar Using retriever augmented large language models for attack graph generation. arXiv preprint arXiv:2408.05855. Cited by: §1, §5. Ramachandran (2026) M. Ramachandran Prompt engineering for secure ai design and cyber defense. In Guide to AI for Cybersecurity, p. 185–210. Cited by: §1. Sancho et al. (2020) J. C. Sancho, A. Caro, M. Ávila, and A. Bravo New approach for threat classification and security risk estimations based on security event management. Future Generation Computer Systems 113, p. 488–505. Cited by: §1, §5. Sanvito et al. (2025) D. Sanvito, G. Arriciati, G. Siracusano, R. Bifulco, and M. Carminati AutoCVSS: assessing the performance of llms for automated software vulnerability scoring. In Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing: Industry Track, p. 564–575. Cited by: §4. Sasikrishna et al. (2026) A. Sasikrishna, J. Subhash, T. Balachander, et al. LLM-orchestrated multi-agent framework for log-centric cyber threat detection and analysis. In 2026 7th International Conference on Intelligent Communication Technologies and Virtual Mobile Networks (ICICV), p. 1490–1497. Cited by: §1. Shahid and Debar (2021) M. R. Shahid and H. Debar Cvss-bert: explainable natural language processing to determine the severity of a computer security vulnerability from its description. In 2021 20th IEEE International Conference on Machine Learning and Applications (ICMLA), p. 1600–1607. Cited by: §4. Sheyner et al. (2002) O. Sheyner, J. Haines, S. Jha, R. Lippmann, and J. M. Wing Automated generation and analysis of attack graphs. In Proceedings 2002 IEEE Symposium on Security and Privacy, p. 273–284. Cited by: §5. Singer (2025) Y. Singer Foundation-sec-8b: cisco foundation ai’s first open-source security model. Cisco. Note: https://blogs.cisco.com/security/foundation-sec-cisco-foundation-ai-first-open-source-security-model Cited by: §4. Strom et al. (2018) B. Strom, A. Applebaum, D. Miller, K. Nickels, A. Pennington, and C. Thomas MITRE att&ck: design and philosophy. Technical report MITRE Corporation. Cited by: 2nd item, §4, §5. Uetz et al. (2024) R. Uetz, M. Herzog, L. Hackländer, S. Schwarz, and M. Henze You cannot escape me: detecting evasions of \siem\ rules in enterprise networks. In 33rd USENIX Security Symposium (USENIX Security 24), p. 5179–5196. Cited by: §1, §5. Vijayaraghavan et al. (2026) B. J. Vijayaraghavan, Y. Meng, S. R. Prakash, M. A. Kefi, S. Kalvakuntla, S. Elkefi, and Z. Xi HopeLink: a large language model-powered clinical information assistant supporting cancer patients’ online information seeking. In IISE Annual Conference. Proceedings, p. 1–7. Cited by: §5. VirusTotal (2004) VirusTotal VirusTotal. Note: https://w.virustotal.com/ Cited by: 5th item, 3rd item, §1. White et al. (2013) J. S. White, T. Fitzsimmons, and J. N. Matthews Quantitative analysis of intrusion detection systems: snort and suricata. In Cyber sensing 2013, Vol. 8757, p. 10–21. Cited by: §1. Zhan et al. (2021) X. Zhan, L. Fan, S. Chen, F. We, T. Liu, X. Luo, and Y. Liu Atvhunter: reliable version detection of third-party libraries for vulnerability identification in android applications. In 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE), p. 1695–1707. Cited by: §1. Zhang et al. (2022) C. Zhang, X. Peng, C. Sha, K. Zhang, Z. Fu, X. Wu, Q. Lin, and D. Zhang Deeptralog: trace-log combined microservice anomaly detection through graph-based deep learning. In Proceedings of the 44th international conference on software engineering, p. 623–634. Cited by: §5. Zhou et al. (2025) X. Zhou, S. Cao, X. Sun, and D. Lo Large language model for vulnerability detection and repair: literature review and the road ahead. ACM Transactions on Software Engineering and Methodology 34 (5), p. 1–31. Cited by: §5. ZySec AI (2024) ZySec AI ZySec-7b. Note: Model on Hugging Face Cited by: §4. Appendix A AI Use Statement In this work, we used generative AI tools mainly to improve the readability of the manuscript through language polishing and grammar checking. We did not use generative AI tools to generate synthetic datasets (note that the “evidence synthesis” in our topic means “evidence integration”, not fabricating data); develop theoretical models or conceptual frameworks (besides that this paper studies on LLM-powered system, rather than using generative AI as tools to develop those systems); formulate mathematical claims; provide ingredients for proving mathematical claims; assist in writing proofs; propose or refine research hypotheses; design or provide feedback on research methodology or experiments; implement the proposed methods; perform translation; clean or reformat datasets; conduct qualitative or thematic data analysis; or interpret experimental results. All AI-assisted language edits were reviewed by the authors. We take responsibility for the final content of this work, including any text produced or edited with the aid of generative AI. Appendix B Reproducibility Statement We provide an anonymized implementation and experimental materials at https://github.com/ltang24/LLM-Prioritization. The complete Polar workflow and algorithms are described in §3, with experimental settings and evaluation protocols reported in §4. Appendix D provides implementation instructions for evidence synthesis, CVSS assessment, temporal exploitation analysis, and mitigation recommendation, while the experimental appendix documents data collection, quality control, dataset statistics, and additional evaluations. Together with the released code, these materials are intended to support reproduction of the reported results. Appendix C Limitations Our evaluation focuses on publicly available vulnerability and cyber threat intelligence sources and therefore does not cover organization-specific private telemetry, asset inventories, or proprietary threat feeds. We study a 30-day exploitation horizon and the mitigation categories considered in our evaluation; other operational environments may use different horizons or remediation workflows. These settings define the scope of our current evaluation, while the evidence-synthesis workflow can be adapted to additional sources and downstream security tasks. Appendix D Complementary Details of Polar We provide implementation details for the evidence synthesis, threat prioritization, and mitigation components introduced in §3. D.1 Real-World Cyber Evidence Synthesis The evidence synthesis stage converts raw cyber reports into the threat-centric evidence zk=(τk,k,ℰk)z_k=( _k,m_k,E_k) used throughout Polar. We first separate entangled threat descriptions and then enrich each threat with source-linked evidence and standardized metadata. D.1.1 Threat Disentanglement A single CTI report can mention several vulnerabilities, campaigns, or attack behaviors. We use an LLM to separate these descriptions while preserving the context associated with each threat. Instruction: Threat Instance Disentanglement System role. You are a cybersecurity analyst processing cyber threat intelligence reports. Separate the input into distinct threat instances. Requirements. • Identify explicit threat indicators such as CVE IDs, affected products, malware, infrastructure, attack techniques, and timestamps. • Create one threat instance for each distinct vulnerability, malware activity, or campaign described in the report. • Preserve the local context of each instance, including the affected component, exploitation behavior, required access, deployment conditions, and relevant source text. • Do not merge two threats only because they appear in the same report. • Do not add facts that are absent from the input. Input. RAW_INCIDENT_TEXT Output. Return a JSON array. Each entry contains: • cve_ids if present, • vendor, product, and affected_component, • attack_behavior, • exploitation_conditions, • timestamps if present, • supporting_spans copied from the input. Each returned entry becomes a canonical threat instance τk _k. We keep the supporting spans because later stages use them as evidence for severity, exploitation, and mitigation analysis. D.1.2 Evidence Metadata Construction and Enrichment After disentanglement, Polar builds the evidence set ℰkE_k and metadata km_k for each threat. The implementation follows four simple steps. Entity linking and evidence clustering. We first link mentions that refer to the same threat. Exact CVE matches provide the strongest key when available. When a CVE is absent, we use the affected vendor/product, component, exploitation behavior, and nearby timestamps to associate reports. Repeated descriptions from different sources are grouped under the same threat while their source information is preserved. Event decomposition and evidence roles. Long descriptions are split into evidence units that describe one relevant observation, such as a vulnerability property, PoC release, exploitation report, or mitigation statement. Each evidence unit follows the representation ek,r=(sk,r,uk,r,tk,r,ck,r)e_k,r=(s_k,r,u_k,r,t_k,r,c_k,r), where sk,rs_k,r is the supporting span, uk,ru_k,r is its source, tk,rt_k,r is its timestamp when available, and ck,rc_k,r records its role. We use four main roles: identity, severity, exploitation, and mitigation. External evidence enrichment. We query external sources using the CVE ID and available aliases of τk _k. The main sources are: • NVD/CVE records for canonical vulnerability descriptions, affected products and versions, disclosure dates, and references (CVE Program, 2024); • MITRE ATT&CK for relevant attacker techniques and behavioral mappings (Strom et al., 2018); • CISA KEV for confirmed exploitation status and associated remediation guidance (Cybersecurity and Infrastructure Security Agency (CISA), 2024); • Exploit-DB and other public exploit sources for PoC availability and publication dates (Offensive Security, 2025); • VirusTotal for malware, URL, file, and related threat observations (VirusTotal, 2004); • vendor advisories, CERT bulletins, CTI reports, and available telemetry for affected configurations, exploitation updates, and remediation context. The standardized metadata km_k contains fields that can be represented directly, such as the CVE ID, vendor/product, affected versions, affected component, disclosure date, and ATT&CK mappings. Free-text observations remain in ℰkE_k with their provenance. Temporal relations and conflicting evidence. Timestamped evidence is normalized to a common date format and ordered by observation time. We retain simple relations such as the same threat appearing across sources and one observation occurring before another. Conflicting claims are not silently overwritten. Both claims remain in ℰkE_k with their sources and dates. For canonical fields such as affected versions or patch availability, we give preference to current vendor or government guidance and mark older information as superseded when the source explicitly indicates an update. These steps produce the shared representation zk=(τk,k,ℰk)z_k=( _k,m_k,E_k). Task-specific views such as ℰk(AV)E_k^(AV) or ℰktempE_k^temp are selected from this same evidence set. Example: Building a Print Spooler evidence metadata Raw report iji_j. A report describes both local privilege escalation and remote Print Spooler exploitation through crafted RPC requests. Disentanglement. ϕLLM(ij) _LLM(i_j) separates the report into distinct threat instances. For the remote exploitation path, τk _k keeps the Print Spooler component, remote access condition, crafted RPC behavior, and resulting code execution. Metadata km_k. Polar links the instance to its CVE record, affected Windows versions, disclosure date, and relevant ATT&CK mappings. Evidence ℰkE_k. Example evidence units include “authenticated remote attacker” from a vendor advisory with role severity, “crafted DCERPC request” with role severity, and a dated KEV observation with role exploitation. Together, τk _k, km_k, and ℰkE_k form zkz_k for the downstream analyses. D.2 Threat Prioritization Details Threat prioritization uses two views of the same evidence metadata: metric-specific evidence for CVSS assessment and temporally ordered evidence for exploitation analysis. D.2.1 CVSS Metric Assessment For each CVSS metric i, Polar selects ℰk(i)⊆ℰkE_k^(i) _k and provides the selected evidence, its provenance, and the official CVSS definition to the LLM. The model returns the categorical value and a short rationale pointing to the decisive evidence. Once all base metrics are assigned, we compute the final score using the official CVSS scoring procedure. The following rules define the evidence used for each metric. Attack Vector (AV). We look for evidence describing how the vulnerable component is reached. Network services and remote requests support Network; communication limited to a shared local network supports Adjacent; execution that requires local system access supports Local; and physical access supports Physical. Protocol and deployment information in km_k is used to confirm the access path. Attack Complexity (AC). We check whether successful exploitation depends on conditions outside the attacker’s control. Race conditions, rare system states, or required non-default configurations can support High. Normal attacker actions such as crafting a request or hosting a payload do not by themselves increase AC. If the documented exploitation path works under ordinary and reproducible conditions, we assign Low. Privileges Required (PR). We determine the minimum privileges needed before exploitation begins. Explicit terms such as “unauthenticated”, “authenticated user”, or “administrator” are mapped to None, Low, or High. Privileges obtained after successful exploitation are not used to determine PR. User Interaction (UI). We check whether successful exploitation requires an action from another user. Opening a malicious document or clicking a link supports Required. Exploitation triggered directly by attacker-controlled requests supports None. Scope (S). We determine whether exploitation can affect a security authority different from the vulnerable component. Evidence about sandbox escape, cross-tenant effects, privilege-domain transitions, or impact on another security boundary is used to distinguish Changed from Unchanged. When the available evidence only describes effects within the same security authority, we use Unchanged. Confidentiality, Integrity, and Availability (C/I/A). We assess the direct impact of successful exploitation. Information disclosure supports confidentiality impact; unauthorized modification or code execution supports integrity impact; and crashes or service disruption support availability impact. Each dimension is assigned independently according to the extent of the documented impact. Handling conflicting evidence. When sources disagree, Polar checks whether the statements describe different versions, configurations, or exploitation paths. Metric assignments use the path and conditions supported by the evidence being scored and follow the official CVSS guidance when several valid paths exist. The model is instructed to cite the evidence that determines each final metric. Example: Evidence-grounded CVSS assessment For the Print Spooler threat above, “authenticated remote attacker” and RPC/DCERPC evidence form part of ℰk(AV)E_k^(AV) and support AV=Network. The same authentication cue contributes to ℰk(PR)E_k^(PR) and supports PR=Low. If the exploitation path requires no victim action, the corresponding evidence supports UI=None. The remaining metrics are determined from their own evidence views before the official CVSS procedure computes sks_k. D.2.2 Temporal Exploitation Assessment The exploitation component estimates how likely a vulnerability is to be observed in exploitation within the next 30 days. We construct the temporal evidence view from evidence available at the analysis time only. Evidence sources. We collect exploitation-related observations from the following sources. • Exploit-DB: PoC availability, exploit type, and publication date (Offensive Security, 2025). • CISA KEV: confirmed exploitation status and KEV addition date (Cybersecurity and Infrastructure Security Agency (CISA), 2024). • VirusTotal: first-seen malware or related file/URL observations when they can be linked to the threat (VirusTotal, 2004). • Vendor advisories and CERT bulletins: dated updates concerning exploitation, PoC availability, patches, and observed campaigns (Computer Emergency Response Team Coordination Center (CERT/C), 1988). • CTI reports and available telemetry: dated observations of scanning, malware activity, exploitation attempts, or campaign adoption. Timeline construction. For each source, we extract a short event record containing its date, event type, source, and supporting text. Dates are normalized, duplicate observations are merged while preserving all sources, and events are sorted chronologically. Evidence published after the analysis cutoff is excluded. The resulting ℰktempE_k^temp may contain events such as disclosure, PoC publication, KEV listing, malware observation, or exploitation in the wild. Exploitation estimation. The LLM receives zkz_k, the CVSS representation kv_k, and the ordered temporal evidence. It is instructed to consider the order and spacing of events, evidence of weaponization, deployment exposure, patch availability, and observed attacker interest. CVSS severity alone is not treated as evidence of active exploitation. Instruction: Temporal Exploitation Assessment System role. Estimate the probability that the vulnerability will be observed in exploitation within the next 30 days. Input. • threat evidence metadata zkz_k; • CVSS metric vector kv_k; • chronologically ordered exploitation evidence ℰktempE_k^temp. Reasoning requirements. • Use only evidence available before the analysis cutoff. • Consider how quickly PoCs or weaponized exploits appeared after disclosure. • Give strong weight to confirmed KEV or in-the-wild exploitation evidence. • Consider whether the affected service is commonly exposed and whether patches are already available. • Do not infer exploitation only from a high CVSS score. Output. Return: • probability: a value in [0,1][0,1]; • supporting_events: the decisive dated observations; • rationale: a short explanation of the estimate. The returned probability is pkp_k. Together with zkz_k and sks_k, it forms the prioritization metadata rk=(zk,sk,pk)r_k=(z_k,s_k,p_k) used for threat ordering. D.3 Mitigation Recommendation Details The mitigation component first retrieves source-linked defensive actions and then orders the applicable actions using the threat metadata produced during prioritization. D.3.1 Candidate Mitigation Retrieval For each zkz_k, we query the remediation corpus remD_rem using the CVE ID, affected product and version, component, and relevant exploitation context. Official vendor guidance is checked first, followed by CISA KEV, NVD references, MITRE ATT&CK, maintainer documentation, CERT bulletins, and trusted security advisories. We organize retrieved material into the four categories used in our evaluation: • CVE-to-patch mappings: fixed versions, patch or hotfix identifiers, release dates, and applicability; • ATT&CK-aligned mitigations: defensive techniques and controls relevant to the observed attack path; • mitigation notes or workarounds: temporary configuration changes, feature disabling, segmentation, isolation, or other compensating controls; • vendor advisories: official remediation guidance and supporting references. Instruction: Mitigation Knowledge Retrieval System role. Retrieve authoritative mitigation actions for the supplied threat metadata. Input. A threat metadata zkz_k containing the CVE ID, affected product/version, affected component, relevant exploitation evidence, and available remediation context. Source order. 1. vendor advisories and official patch bulletins; 2. CISA KEV mitigation guidance; 3. NVD references; 4. MITRE ATT&CK mitigation knowledge; 5. official maintainer or project documentation; 6. trusted CERT or security advisories. For each candidate action, return: • action type; • recommended action; • affected and fixed versions when available; • source and publication/update date; • applicability conditions; • operational notes or limitations; • whether the guidance supersedes an older action. Output. Return four groups: CVE-to-Patch, ATT&CK Mitigation, Mitigation Notes/Workarounds, and Vendor Advisories. Normalization and applicability filtering. Semantically equivalent actions from different sources are merged into one candidate while all supporting sources are retained. If a newer vendor advisory explicitly replaces an older patch or workaround, the older entry is marked as superseded. Actions that do not apply to the affected product or version in zkz_k are removed. Temporary workarounds remain available when a patch cannot yet be applied. The resulting threat-specific candidate set is k=ak,1,…,ak,JkA_k=\a_k,1,…,a_k,J_k\. D.3.2 Mitigation Ordering The final stage receives the prioritized threat metadatas rk\r_k\ and their candidate actions k\A_k\. It uses the existing threat priority together with action-level evidence to produce the ordered mitigation plan Πmit _mit. We do not introduce a separate hand-designed risk formula in this stage. Instruction: Risk-Aware Mitigation Ordering System role. Produce an ordered and implementable mitigation plan from the prioritized threats and their source-grounded candidate actions. Input. For each threat: • rk=(zk,sk,pk)r_k=(z_k,s_k,p_k); • applicable candidate actions kA_k; • available information about patch availability, workaround effectiveness, implementation effort, and operational disruption. Ordering rules. 1. Follow the threat priority produced by the prioritization stage. 2. Prefer an applicable vendor patch or fixed release when it can be deployed safely. 3. If immediate patching is not possible, place effective vendor-supported workarounds or compensating controls earlier in the plan. 4. For threats with strong exploitation evidence or high pkp_k, prioritize actions that can reduce exposure immediately. 5. Consider implementation complexity and operational disruption when actions provide similar protection. 6. Do not recommend an action if its product, version, or deployment conditions do not match zkz_k. 7. Keep the authoritative source attached to every recommendation. Output. Return an ordered list with: • target; • recommended_action; • action_type; • source; • priority_rationale; • dependencies_or_operational_notes. This produces the source-linked mitigation plan Πmit _mit described in §3.3. The same threat evidence therefore supports both stages of the workflow: prioritization determines which threats are urgent, and mitigation selects the actions that fit those threats. Appendix E Additional Details of Experiment E.1 Data Collection and Quality Control Raw Incident Collection. We collect raw threat incidents from multiple trusted sources, including vendor advisories (e.g., Microsoft, Cisco, Oracle, Adobe), security research reports (e.g., Mandiant, Unit 42, Recorded Future), public CTI aggregators (e.g., the CISA KEV catalog (Cybersecurity and Infrastructure Security Agency (CISA), 2024) and US-CERT bulletins (Computer Emergency Response Team Coordination Center (CERT/C), 1988)), and exploit repositories (e.g., Exploit-DB (Offensive Security, 2025) and GitHub PoCs). Each incident is preserved in its original form, including textual advisories, PDF bulletins, blog posts, and structured feeds, so that the evaluation reflects the heterogeneous evidence encountered in practice. We exclude low-confidence or non-authoritative sources and require each incident to be corroborated by at least one vendor advisory or government-maintained repository. This process provides reliable and context-rich inputs for subsequent evidence synthesis and analysis. I: Real-World Cyber Evidence Synthesis. Our collection and quality-control procedure follows the evidence-profile fields defined in Appendix §D.1.2. We construct reference information for the threat instances and source-linked evidence used by Polar. 1. CVE and Vulnerability Identification. Each candidate threat is validated against the CVE and NVD databases. Vulnerabilities used in this evaluation require an official CVE identifier and corresponding NVD entry. 2. Tactics, Techniques, and Procedures (TTPs). Threat instances are mapped to MITRE ATT&CK tactics and techniques using advisory text and official ATT&CK references. For example, a Print Spooler vulnerability may align with T1068 (Exploitation for Privilege Escalation) and T1210 (Exploitation of Remote Services). 3. Affected Systems and Vendors. Vendor, product, and version mappings are verified against NVD records and vendor advisories. For each threat, we record the affected operating systems or applications, product families, versions, and relevant architectural constraints. 4. Exploitation and Exposure Status. We cross-check exploitation evidence using the CISA KEV catalog, public exploit repositories such as Exploit-DB and Metasploit, and vendor or CERT bulletins. KEV listings and public exploit records are retained as separate source-linked observations because they capture different forms of exploitation evidence. 5. Disclosure and Advisory Context. Each threat is enriched with disclosure information, including the initial disclosure source and the chronology of advisory publication, exploit release, patch issuance, and subsequent updates when available. I: CVSS Severity Assessment. Reference severity labels are obtained from official NVD CVSS v3.1 vectors. For each threat instance, we retrieve the categorical vector (AV/AC/PR/UI/S/C/I/A) and its corresponding base score. We apply the following quality-control rules: 1. If multiple CVSS entries exist because of revisions or vendor-specific scoring, we use the latest NVD-assigned vector as the reference. 2. Ambiguous or disputed CVSS assignments are flagged and excluded from evaluation. 3. We retain both categorical metric values (e.g., AV:N) and numerical severity scores for evaluation. I: Temporal Exploitation Assessment. Reference exploitation likelihood is obtained from the FIRST.org Exploit Prediction Scoring System (EPSS). For each CVE, we retrieve the EPSS probability and percentile associated with a fixed evaluation date. EPSS estimates exploitation within the following 30 days and therefore matches the primary prediction horizon used by Polar. To ensure consistent evaluation: • EPSS scores are collected using a fixed snapshot synchronized with the evaluation window. • CVEs without an available EPSS score are excluded from exploitation-probability evaluation. • We retain both the raw probability and percentile rank for absolute and relative comparisons. IV: Mitigation Recommendation. Reference mitigation items are collected from authoritative sources and organized into the same four categories used by Polar: CVE-to-patch mappings, ATT&CK-aligned mitigations, mitigation notes or workarounds, and vendor advisories. 1. CVE-to-Patch Mapping. We retrieve patch records linked to each CVE and cross-check them against vendor advisory portals such as Microsoft MSRC, Cisco PSIRT, and Oracle CPU. Each entry records affected versions, fixed releases or patch identifiers, and publication dates. We retain vendor-confirmed or NVD-linked records and explicitly mark superseded patches. 2. ATT&CK-Aligned Mitigation. Defensive actions are collected from MITRE ATT&CK’s mitigation catalog and associated with the relevant ATT&CK techniques. For example, T1210 (Exploitation of Remote Services) may be associated with M1031 (Network Intrusion Prevention) and M1051 (Update Software). We retain mappings supported by official ATT&CK references or corresponding vendor guidance. 3. Mitigation Notes and Workarounds. We collect remediation guidance from the CISA KEV catalog and other authoritative advisories. For KEV-listed vulnerabilities, we record remediation deadlines, required actions, and interim mitigations when available. Conflicting dates or instructions are resolved using the latest vendor-issued guidance. 4. Vendor Advisories. Vendor advisories provide the primary reference for patches, hotfixes, and configuration workarounds. We record the official advisory identifier, recommended remediation, applicable product versions, and documented operational side effects when available. Only advisories hosted on official vendor portals are used unless a secondary source is explicitly linked by the vendor. Data Statistics. Table 3 summarizes the collected incidents and corresponding evidence used across the evaluation stages. Table 3: Dataset statistics across the evaluation stages of Polar. Numbers are rounded and reported in xK format. Stage Detailed Item Count Raw threat incidents collected 12.8K I. Evidence Synthesis CVE-mapped instances 12.8K MITRE ATT&CK TTP mappings 12.8K Affected vendor/product metadata 12.8K Exploitation / exposure status annotated 12.8K Disclosure and advisory context enriched 11.6K I. Severity Assessment CVSS vectors (official NVD) 12.8K Metric-specific evidence sets 12.8K Fully scored CVSS severities 12.8K I. Temporal Exploitation EPSS probabilities (FIRST.org) 12.8K Exploit-DB / PoC references 6.8K Confirmed CISA KEV exploited CVEs 0.8K IV. Mitigation Recommendation CVE-to-patch release mappings (NVD + vendor) 9.9K ATT&CK mitigation mappings 5.2K CISA KEV mitigation notes 0.4K Vendor advisories (patches / workarounds) 8.7K E.2 Additional Results and Discussions E.2.1 Evidence Synthesis Effectiveness Sources of performance gains. A closer inspection of Polar outputs shows that gains in evidence synthesis mainly come from grounding raw reports in authoritative external sources. Three forms of evidence are especially useful: 1. Threat-to-record linking. Grounding advisory text against NVD records reduces ambiguity when several vulnerability identifiers appear together. For example, when an advisory discusses multiple Print Spooler CVEs, evidence linking allows each threat instance to retain the correct affected product and version. 2. MITRE ATT&CK mappings. ATT&CK grounding provides consistent behavioral context for otherwise ambiguous descriptions. For example, wording such as “gaining higher privileges through system calls” can be linked to T1068 (Exploitation for Privilege Escalation) when supported by the underlying evidence. 3. Disclosure and exploitation evidence. KEV records and disclosure chronology help distinguish confirmed exploitation from less certain reports. An advisory mentioning “public reports of exploitation,” for example, is treated as confirmed in-the-wild exploitation only when supported by an authoritative source such as KEV or a vendor advisory. Together, these sources improve the quality of the threat-centric evidence profile zkz_k before it is used for severity, exploitation, or mitigation analysis. Nature of mistakes. Two recurring errors remain. First, some LLM backbones occasionally produce unsupported CVE identifiers when reports are long or contain several related vulnerabilities. Second, unsupported ATT&CK mappings can appear when the model extrapolates beyond the available evidence. Both errors arise when the model fills missing information using prior knowledge rather than remaining grounded in the supplied sources. Detectability of unsupported outputs. These errors can usually be identified with lightweight validation: • generated CVE identifiers can be checked against the CVE/NVD corpus; • ATT&CK identifiers can be validated against the official ATT&CK taxonomy; • claims of active exploitation can be checked against KEV and dated vendor advisories. These checks complement evidence synthesis by preventing unsupported identifiers or exploitation claims from propagating to downstream assessment. Takeaways. The gains in this stage come from linking LLM reasoning to source-grounded evidence. External validation is especially useful for entity linking, ATT&CK mapping, and exploitation status, where unconstrained generation can otherwise introduce plausible but unsupported information. E.2.2 Ablation Study We provide additional discussion complementing the ablation results reported in Table 2 of §4.2. Findings. Removing any component consistently reduces end-to-end performance, showing that the stages provide complementary information. Removing Evidence Synthesis causes substantial degradation because downstream stages lose the disentangled and source-grounded threat profile. Removing Severity Assessment mainly affects severity-sensitive ranking and patch alignment, while removing Temporal Exploitation Assessment reduces the ability to distinguish threats with similar severity but different exploitation dynamics. Component interactions. The stages also reinforce one another. Temporal exploitation evidence is most useful when it is attached to a correctly identified threat, while CVSS assessment benefits from metric-specific evidence selected from the synthesized profile. Evidence synthesis therefore provides the shared representation on which both downstream assessments depend. Implications for pipeline design. The modular design allows individual components to be updated without redesigning the full workflow. Improvements to threat disentanglement, evidence enrichment, CVSS interpretation, or temporal evidence collection can be incorporated while preserving the same threat-centric interface between stages. E.2.3 Zero-Day Analysis We evaluate Polar on zero-day vulnerabilities to study early-stage threat assessment when CVE identifiers, complete metadata, or official severity scores are unavailable at decision time. In this setting, Polar relies primarily on raw incident descriptions and emerging cyber evidence. Table 4: Zero-day threat prioritization and mitigation performance under partial-information settings. All results are the mean and standard deviation over five runs. All metrics except Kendall’s τ are reported in percentage (%). Method NDCG@5 Kendall’s τ Mitigation Recall@5 Mitigation F1 Severity-only Heuristic 51.2 ± 1.2 0.403 ± 0.019 46.1 ± 1.4 42.8 ± 0.9 EPSS-inspired Ranking 53.8 ± 1.4 0.421 ± 0.015 48.7 ± 0.6 45.1 ± 1.1 Backbone LLM (no framework) 60.3 ± 1.5 0.497 ± 0.013 55.2 ± 0.6 51.8 ± 1.3 Polar 71.2 ± 0.5 0.623 ± 0.012 68.4 ± 1.2 65.1 ± 0.5 Discussion. As shown in Table 4, Polar substantially outperforms heuristic and backbone-only baselines under partial-information conditions. Although all methods degrade relative to fully documented vulnerabilities, Polar retains stronger prioritization accuracy and mitigation recall by synthesizing the evidence that remains available. Qualitative inspection also shows that Polar can recover useful mitigation actions and relative threat ordering before complete vulnerability records become available. E.2.4 CVSS Severity Assessment Effectiveness Sources of Polar’s gains. The largest gains in CVSS assessment occur when advisory text contains ambiguous or incomplete cues. Polar improves these decisions by selecting evidence relevant to each CVSS dimension: 1. Attack Vector (AV). Advisories may describe a vulnerability as “remotely exploitable” without clearly identifying the required access path. Linking the affected component to protocol and deployment evidence helps resolve cases such as RPC over SMB as AV=Network. 2. Attack Complexity (AC). Generic LLM predictions can overlook conditions such as race requirements, unusual configurations, or deployment dependencies. Metric-specific evidence helps distinguish these cases from ordinary low-complexity exploitation. 3. Privileges Required (PR) and User Interaction (UI). Explicit evidence such as “authenticated attacker” or “user must open a crafted document” is selected from the threat profile and used directly for the corresponding CVSS decision. Consistency across metrics. The same evidence-grounded procedure also improves Scope and the confidentiality, integrity, and availability dimensions by aligning free-text consequences with the corresponding CVSS definitions. Remaining gaps. Errors remain when advisories omit important technical details or when exploitation conditions differ across product versions. For example, vague descriptions such as “may allow elevation of privilege under certain conditions” may not contain enough information to cleanly separate privilege requirements from attack complexity. Version-specific behavior can also cause errors when the same CVE affects several platforms differently. Takeaways. Overall, the results show that selecting source-linked evidence for each CVSS metric improves both categorical metric prediction and the resulting severity score. This supports the design of Polar’s evidence-grounded severity assessment. E.2.5 Temporal Exploitation Assessment Experimental Setting. We further study temporal exploitation assessment under two conditions: (1) different exploitation trajectories, including stable, increasing or decreasing, and abrupt-change patterns; and (2) different lengths of historical evidence supplied to the model. Table 5 reports forecasting performance across exploitation trajectories, while Figure 5 studies the effect of historical context length. The primary Polar setting estimates exploitation within 30 days; we additionally report a 90-day horizon to examine sensitivity to longer prediction windows. Table 5: Temporal exploitation forecasting by trend type using a one-year exploitation history to predict the next 30 and 90 days. Each cell reports Polar-enhanced results together with the change relative to the corresponding backbone model. ↓ indicates reduced RMSE and ↑ indicates improved direction accuracy (DirAcc), which measures whether the exploitation trend is increasing, decreasing, or stable. All results are the mean and standard deviation over five runs. Results for cybersecurity-specialized agents are provided in Table 6. Model 30 Days 90 Days RMSE (×10−3× 10^-3) ↓ DirAcc (%) ↑ RMSE (×10−3× 10^-3) ↓ DirAcc (%) ↑ Monotonic trend of exploitation (increasing/decreasing) POLAR + GE3.1 1.141 ± 0.029 (↓ 0.587) 89.6 ± 0.6 (↑ 12.1) 1.426 ± 0.053 (↓ 0.479) 82.1 ± 1.3 (↑ 9.0) G5 1.389 ± 0.049 (↓ 0.341) 85.2 ± 1.0 (↑ 7.8) 1.738 ± 0.055 (↓ 0.279) 78.1 ± 1.5 (↑ 5.7) L70B 1.622 ± 0.057 (↓ 0.108) 81.4 ± 1.0 (↑ 6.1) 2.029 ± 0.044 (↓ 0.089) 74.7 ± 1.4 (↑ 4.5) C4.1 1.098 ± 0.053 (↓ 0.629) 90.4 ± 0.6 (↑ 13.9) 1.373 ± 0.047 (↓ 0.515) 82.9 ± 1.2 (↑ 10.2) Q3 1.532 ± 0.035 (↓ 0.198) 82.6 ± 1.2 (↑ 6.4) 1.916 ± 0.071 (↓ 0.162) 75.9 ± 0.8 (↑ 4.7) Stable trend of exploitation (no significant change) POLAR + GE3.1 0.167 ± 0.006 (↓ 0.098) 48.7 ± 0.5 (↑ 8.9) 0.210 ± 0.010 (↓ 0.080) 42.2 ± 1.1 (↑ 6.9) G5 0.215 ± 0.007 (↓ 0.051) 43.8 ± 0.4 (↑ 5.9) 0.269 ± 0.007 (↓ 0.042) 37.9 ± 1.3 (↑ 4.6) L70B 0.247 ± 0.009 (↓ 0.019) 41.7 ± 0.9 (↑ 4.0) 0.309 ± 0.015 (↓ 0.015) 36.1 ± 0.5 (↑ 3.1) C4.1 0.163 ± 0.004 (↓ 0.103) 49.2 ± 0.9 (↑ 9.4) 0.204 ± 0.005 (↓ 0.084) 42.6 ± 1.1 (↑ 7.3) Q3 0.231 ± 0.006 (↓ 0.035) 42.7 ± 0.7 (↑ 3.4) 0.290 ± 0.010 (↓ 0.028) 36.9 ± 1.4 (↑ 2.6) Abrupt change of exploitation POLAR + GE3.1 61.473 ± 2.346 (↓ 40.764) 61.4 ± 0.7 (↑ 14.1) 76.385 ± 3.019 (↓ 33.402) 53.3 ± 0.8 (↑ 11.0) G5 75.212 ± 1.873 (↓ 27.121) 54.6 ± 1.5 (↑ 7.4) 93.389 ± 3.641 (↓ 22.219) 47.4 ± 1.5 (↑ 5.8) L70B 84.442 ± 1.835 (↓ 17.891) 48.9 ± 1.5 (↑ 1.7) 104.828 ± 2.636 (↓ 14.653) 42.4 ± 1.2 (↑ 1.3) C4.1 59.540 ± 2.626 (↓ 42.792) 62.5 ± 1.0 (↑ 15.2) 73.920 ± 2.926 (↓ 35.068) 54.2 ± 1.0 (↑ 11.8) Q3 82.821 ± 3.538 (↓ 19.512) 49.6 ± 0.7 (↑ 2.5) 102.841 ± 2.616 (↓ 15.981) 43.0 ± 1.0 (↑ 1.9) Table 6 complements the results in Table 5 for cybersecurity-specialized agents. Table 6: Additional temporal exploitation forecasting results by trend type, continuing Table 5. All results are the mean and standard deviation over five runs. Model 30 Days 90 Days RMSE (×10−3× 10^-3) DirAcc (%) RMSE (×10−3× 10^-3) DirAcc (%) Monotonic trend of exploitation (increasing/decreasing) POLAR + FS 2.385 ± 0.099 (↓ 0.341) 61.8 ± 0.6 (↑ 0.1) 2.928 ± 0.115 (↓ 0.279) 56.2 ± 1.3 (↑ 0.1) LY 2.216 ± 0.100 (↓ 0.510) 63.0 ± 1.3 (↑ 0.2) 2.721 ± 0.113 (↓ 0.417) 57.5 ± 0.8 (↑ 0.2) ZY 2.127 ± 0.047 (↓ 0.599) 63.5 ± 0.7 (↑ 0.3) 2.612 ± 0.088 (↓ 0.490) 58.0 ± 0.9 (↑ 0.2) Stable trend of exploitation POLAR + FS 0.349 ± 0.010 (↓ 0.003) 34.1 ± 1.3 (↑ 0.2) 0.437 ± 0.014 (↓ 0.002) 29.6 ± 1.0 (↑ 0.1) LY 0.337 ± 0.016 (↓ 0.003) 35.3 ± 0.9 (↑ 0.2) 0.422 ± 0.014 (↓ 0.003) 30.6 ± 1.0 (↑ 0.2) ZY 0.324 ± 0.009 (↓ 0.004) 36.1 ± 0.8 (↑ 0.3) 0.407 ± 0.015 (↓ 0.003) 31.3 ± 1.2 (↑ 0.2) Abrupt change of exploitation POLAR + FS 102.847 ± 2.174 (↓ 13.485) 44.2 ± 1.5 (↑ 0.5) 127.693 ± 4.243 (↓ 11.041) 38.4 ± 0.9 (↑ 0.4) LY 99.264 ± 3.945 (↓ 17.069) 44.9 ± 0.6 (↑ 0.6) 123.208 ± 5.278 (↓ 13.980) 38.9 ± 1.6 (↑ 0.4) ZY 97.739 ± 1.979 (↓ 18.594) 45.4 ± 0.5 (↑ 0.6) 121.298 ± 5.887 (↓ 15.227) 39.4 ± 0.8 (↑ 0.5) Polar’s robustness across exploitation trajectories. Across the trajectories in Table 5, Polar consistently improves exploitation estimates. Baseline models can follow gradual increases or decreases but respond less reliably to sudden changes. Polar performs better in these cases by connecting recent temporal signals with the surrounding exploitation history. Figure 4: Overall CVSS severity scoring performance measured by RMSE. Figure 5: RMSE under varying historical context lengths for temporal exploitation assessment. Longer temporal context is not always beneficial. Figure 5 shows that adding older exploitation history does not always improve prediction. Earlier observations can introduce evidence from outdated campaigns or product versions that is less relevant to the current threat state. This result suggests that temporal evidence should be selected according to the operational horizon rather than accumulated without limit. Polar remains more robust than the corresponding baselines as additional context is introduced. Sources of Polar’s gains. The largest improvements appear under abrupt changes in exploitation activity. In these cases, recent events such as PoC releases or new exploitation reports alter the meaning of the earlier evidence. By retaining event order and temporal context, Polar adapts more quickly to these changes than models operating on less structured inputs. Observed gaps. Although Polar responds more effectively to abrupt changes, its probability estimate may still lag during the first days of a sudden exploitation surge when little precursor evidence is available. Takeaways. These results show that temporal evidence is most useful when recent observations are interpreted in the context of the broader exploitation history. Future work may further improve responsiveness through more frequent evidence updates or adaptive selection of the temporal context window. E.2.6 Mitigation Recommendation Effectiveness Experimental Setting. We evaluate the final application from two complementary perspectives: (1) the correctness of threat prioritization using NDCG@5 and Kendall’s τ, and (2) mitigation retrieval accuracy measured by F1. Mitigation actions are evaluated across the four categories used throughout the paper: CVE-to-patch mappings, ATT&CK-aligned mitigations, mitigation notes, and vendor advisories. Table 7: Evaluation of prioritization and mitigation recommendation across Polar-enhanced cybersecurity agents and general-purpose LLM backbones. Mitigation retrieval is measured by F1 against reference items from authoritative sources. The reported values show the Polar-enhanced result and the change (↑ or ↓ ) relative to the corresponding backbone model. Model Prioritization Correctness Mitigation Retrieval NDCG@5 Kendall’s τ CVE-to-Patch ATT&CK Mapping Mitigation Note Vendor Advisory Cybersecurity-specialized agent Polar + FS 0.685 (↑ 0.083) 0.553 (↑ 0.101) 0.734 (↑ 0.113) 0.635 (↑ 0.132) 0.693 (↑ 0.091) 0.625 (↑ 0.073) LY 0.694 (↑ 0.092) 0.564 (↑ 0.112) 0.717 (↑ 0.096) 0.624 (↑ 0.121) 0.683 (↑ 0.081) 0.616 (↑ 0.064) ZY 0.705 (↑ 0.103) 0.575 (↑ 0.123) 0.742 (↑ 0.121) 0.646 (↑ 0.143) 0.704 (↑ 0.102) 0.634 (↑ 0.082) General-purpose LLM Polar + GE 0.793 (↑ 0.191) 0.693 (↑ 0.241) 0.844 (↑ 0.223) 0.757 (↑ 0.254) 0.845 (↑ 0.243) 0.743 (↑ 0.191) G5 0.873 (↑ 0.271) 0.783 (↑ 0.331) 0.943 (↑ 0.322) 0.815 (↑ 0.312) 0.903 (↑ 0.301) 0.823 (↑ 0.271) L70B 0.765 (↑ 0.163) 0.673 (↑ 0.221) 0.824 (↑ 0.203) 0.744 (↑ 0.241) 0.814 (↑ 0.212) 0.735 (↑ 0.183) C4.1 0.834 (↑ 0.232) 0.743 (↑ 0.291) 0.904 (↑ 0.283) 0.804 (↑ 0.301) 0.884 (↑ 0.282) 0.805 (↑ 0.253) Q3 0.806 (↑ 0.204) 0.714 (↑ 0.262) 0.872 (↑ 0.251) 0.774 (↑ 0.271) 0.863 (↑ 0.261) 0.785 (↑ 0.233) Polar’s effectiveness in prioritization and mitigation recommendation. Results in Table 7 show consistent gains in both threat ordering and mitigation retrieval. For prioritization, higher NDCG@5 and Kendall’s τ indicate that combining severity sks_k with exploitation likelihood pkp_k produces an ordering closer to the reference urgency ranking, particularly when several threats have similar static severity. For mitigation recommendation, Polar improves retrieval across all four categories. The gains are especially visible for ATT&CK-aligned mitigations and mitigation notes, where recommendations depend on the exploitation path and surrounding threat context. These results show that the synthesized evidence profile supports both finding applicable defensive actions and connecting them to the threats that require attention. Sources of gains. The improvement is most pronounced for mitigation categories that require evidence to be connected across sources. Baseline models can rely heavily on lexical similarity, while Polar uses the threat profile to connect the affected product, exploitation behavior, and current threat evidence to corresponding defensive guidance. The same source and temporal information also helps filter outdated mitigation notes when newer vendor guidance is available. Remaining gaps. Some errors remain for vendor-specific advisories, particularly when highly specific remediation instructions are embedded in long or inconsistently formatted documents. Sparse or conflicting severity and exploitation evidence can also affect the ordering of threats with otherwise similar profiles. Case Study: Competing Threats. In one evaluation batch, two medium-severity vulnerabilities competed for mitigation resources: one affected a widely deployed web framework with active exploit scripts, while the other affected a peripheral library with limited exposure. A severity-driven baseline assigned similar urgency to both. Polar ranked the first threat higher because the synthesized evidence contained stronger exploitation signals, producing an ordering consistent with the reference threat priority. Practical Implications. The results suggest that Polar is useful when many vulnerabilities compete for limited remediation capacity. Its shared evidence representation supports both threat ordering and the retrieval of applicable mitigation actions, reducing the need to repeat evidence collection separately for each decision. Future Directions. Future extensions may incorporate more structured vendor feeds, improve uncertainty handling when evidence conflicts, and model deployment constraints such as patching cost or expected downtime when constructing mitigation plans.

Instant research discovery