On the telecom operator pentest last year, I killed two days perimeter - WAF, minimum surface, standard story. The entry point was found where they did not wait: Jira Service Management, exposed to contractors. Self-registration on Service Desk, account in three minutes, then SSRF via batch endpoint Mobile Plugin. Forty minutes after registration, I have already read cloud-based instantanes and IAM-role tokens. The SOC saw the alterta in six hours. ITSM platforms - Jira SM, ServiceNow, Freshservice - live in a privileged zone of trust of the corporate network, store data on assets, accounting and incidents, integrated with Slack, GitHub, PagerDuty and AD. At the same time, in the payroll, they are included last - if at all.
Business logic of attack: why break ticking
ITSM-platform is not a headlapse, but a registry of the entire IT infrastructure and a configuration management point. For the attacker, value is determined by three things.
CMDB as an infrastructure map. The ticketing system includes lists of servers, network segments, applications and their owners - this is Data from Information Repositories (T1213, Collection) One SSRF with access to the internal API - and the attacker receives a card of all infrared without a single scan. Why make noise with nmap, when everything is already neatly arranged on the shelves?
Credential harvesting from typets. Employees apply configes with passwords, screenshots, links to internal resources - Credentials In Files (T1552.001, Credential Access) ServiceNow Knowledge Base, Confluence next to Jira is a repository of secrets to which it is enough to get reading.
Lateral movement through integration. Integrations with GitHub, Slack, PagerDuty, Jenkins use OAuth tokens and webhook secrets - Trusted Relationship (T1199, Initial Access) Compromise ITSM gives access to all connected systems through trusted connections - without having to break each separately.
From the point of view of kill chain, attacks through the ticking system work on the phase of initial access - Exploit Public-Facting Application (T1190) - when Jira or Service Now stick out for contractors - and when post-exploitation on the internal network, when the attacker searches for a way to domain admin through trusted connections of the ITSM platform.
SSRF attacks via Mobile Plugin for Jira (CVE-2022-26135)
CVE-2022-26135 - server-side request forgery in Mobile Plugin for the Jira Data Center and Server, discovered by the guys from Assetnote. The vulnerability also affects the Jira Service Management Server/Data Center, as Mobile Plugin is included. CVSS 6.5 (MEDIUM), CVSS vector:3.1/AV:N/AC:L/L:L/UI:N/C/I:N/I:N/A:N. Classification CWE-918 (Server-Side Request Forgey). CISA SSVC solution - Track, not confirmed by mass operation, CVE is absent from CISA KEV.
Affected by Atlassian Jira Server and Data Center versions 8.0.0 ≤ v < 8.13.22, 8.14.0 ≤ v < 8.20.10, 8.21.0 ≤ v < 8.2.24., as well as Jira Service Management Server and Data Center versions 4.0.0 ≤ v < 4.13.22, 4.14.0 ≤ v < 4.12.0 ≤ v < 4.2.2.0. According to CISA SSVC - technical impact partial, automation is not confirmed, but the EPSS 0.84 indicates a high model probability of operation (EPSS - probability assessment based on signs of vulnerability and public activity, and not an indicator of confirmed attacks in-the-wild).
Vulnerability Mechanics and Operation Chain
The root of the problem is class BatchServiceImpl.java in Mobile Plugin. Endpoint /rest/ receives a JSON array of requests and executes them on the server side. According to Assetnote, the URL is formed through concatenation URI.create(this.jiraBaseUrls.baseUrl() + path). The attacker transmits to location Meaning @targethost.com, and it turns out the URL https://[email protected]. HTTP client OkHttpClicent interprets part to @ how userinfo and sends a request for targethost.com. Elegant and simple.
SSRF (assetnote) features: sending up to 5 queries simultaneously via batch API, arbitrary HTTP method, arbitrary headers, and query body. Restrictions: The protocol is not directly controlled (needed HTTP-edit to change HTTPS to HTTP), the Host title may not be substituted.
Critical nuance - SSRF requires authentication. But the Jira Service Desk (often installed next to Jira Core) supports self-registration through /servicedesk/customer/user/signup. Service Desk account gives access to the REST API Jira Core - Valid Accounts (T1078, Initial Access) According to the documents - the service Desk account is limited. In practice, it is enough for SSRF.
Full chain of attack:
1. ReconRecon: Recore Jira on the perimeter, determination of the version through /rest/api/2/serverInfo
2. Self-registration : Creating an account via Service Desk signup (T1078)
3. SSRF : request for batch endpoint with payload @internal-host
4. Pivot : reading cloud metadata (169.254.169.254), access to the internal API
5. Post-exploitation : Requiring tokens, CMDB data, piston to internal services
Assetnote has published a technical review with a description of the PoC in their blog (assetnote.io/resources/research) The existence of a separate public PoC repository requires verification before use.
When the technique is NOT working:
• Jira Cloud - another architecture, Mobile Plugin is not installed as an on-prem component
• Pattated versions (8.13.22+, 8.20.10+, 8.2.24.+)
• Self-registration is disabled and no valid account details
• Network segmentation: SSRF is useless if Jira is isolated from sensitive services
• WAF with rules on SSRF-patterns in JSON body (happened, but happens)
STI vulnerability ServiceNow and Freshservice: templaters as an input point
ITSM platforms use templaters to render email notifications, self-service portals and dashboards. Server-side template injection in helpdesk-cheblobnizers - a vector that Russian-speaking sources do not cover at all, although in practice it is regularly found.
Freshservice works with Liquid-like templates for customization of email notifications and portal. On one of the projects, I found that the "Theme of the Appeal" field was rendered through a template builder without shielding: payload {{7*7}} in the topic of the ticket returned 49 in the email notification to the operator - the classic SSTI marker. Liquid has a sandbox that limits a set of available filters and tags, so that full RCE through pure Liquid is unlikely without additional primitives. But reading the configuration and environment variables is a realistic scenario.
ServiceNow uses Jelly (Apache Jelly) for UI server rendering and Glide scripts in JavaScript (T1059.007, Execution) for business logic. Caste-based workflow scripts and Scripted REST API are the main surface for code injection. On several projects, I used SSRF via custom workingflow scripts ServiceNow, where the user input from the ticket got into the server script without sanitation. Injection in Glide-context can give the execution of an arbitrary server code, but for this purpose the input must get into GlideRecord or GlideAjax request.
Restrictions of STI in ITSM:
• The attack requires that the user input is rendered in a template context - depends on the customization of a particular instance
• SaaS versions (cloud) are usually more strictly isolated than on-premise
• ServiceNow ACL-policies restrict access to the emailload delivery API
• SSTI testing generates email notifications - without the consent of the customer it is easy to burn (and spoil the relationship)
Abuse webhook integrations: off address via helpdesk
[Applicable: internal pentest, post-exploitation after receiving admin-access to ITSM]
The operation of ITSM integrations is perhaps the most underappreciated vector. Every integration is trust boundary that no one simulates in a threat model. I'm bumping at this over and over again.
Jira SM -> GitHub/Bitbucket. Webhook notifications when creating tickets transmit data in the repository. Reverse integration uses OAuth tokens with read and write rights. Compromise of Jira - access to the source code. According to the Exalate Integration Review, the typical Ligale of the Jira-ServiceNow synchronizes the ticklet fields, comments, attachments and statuses is a gidanrection overall. Each of these channels is a potential vector for data injection or interception.
ServiceNow -> Slack/Teams. Integrations for notifications use bot-tokens with broad rights. Through these tokens, you can read channels, send messages on behalf of the bot, collect data from chats - Web Protocols (T1071.001, Command and Control)
Freshservice -> PagerDuty/OpsGenie. Webhook secrets are stored in the integration configuration. When accessing the admin panels, these secrets are extracted and used to manipulate the incident process.
In red team-projects OAuth-tokens of integrations are often stored in the open form in the ITSM platform configuration. Having received administrative access - for example, through privilege escalation - for example, CVE-2026-9614 (Improper Access Control in Ivanti Neurons for ITSM, CVSS 8.8 HIGH, CWE-284; there are no technical details and there are no public PoCs, SSVC Exploitation=none, EPSS 0.004 - is given exclusively as an illustration of the privilege escalation class, not a working vector) - the attacker potentially extracts tokens of all connected systems (if there is a working operator).
Webehook work as a bidirectional vector. If the attacker controls the target URL - through SSRF or administrative access - three paths open: intercepting data from the ticket by redirecting webhook to a controlled server, an injection for an automation trigger and creating false tickets, harvesteddentialing from webhook data that contain internal identifiers and sometimes tokens.
Adjustments to the environment
• OS : any with support for Burp Suite Pro (Windows/macOS/(GNU/Linux))
• RAM: at least 8 GB (Burp Suite + browser + nuclei), recommended 16 GB when running parallel with several instances
• Tools : Burp Suite Pro (2024.x+), nuclei (ProjectDiscovery, actively supported, weekly updates), curl
• Network : Access to Target ITSM-Instand - External or via VPN for Internal Pentest
• Additionally : custom nuclei templates for CVE specific ITSM-platforms
Step 1: Definition of platform and version
For Jira - endpoint /rest/api/2/serverInfo returns the version, type of deck and build number. No authentication: the title X-ASEN In response, the patterns in HTML login pages. ServiceNow - endpoint stats.do (if not closed by ACL), cookie pattern glide_session_store, version in HTML comments. Freshservice is defined by HTTP response headers, URL patterns (/support/tickets/), meta tags.
Step 2: Test self-registration
For Jira: POST on /servicedesk/customer/user/signup. The presence of endpoint does not guarantee the included registration - you need to send a real request (according to Assetnote data). For ServiceNow: check /self_registration.do.
Step 3: Scanning known CVE
Step 4: The Integration Audit
If there is administrative access (or after the privilege escalation): extract OAuth-tokens, webhook-URL and API keys from the integration section. Check the rights of each token - often they are redundant. In practice, I have never seen anyone reviving the rights of OAuth tokens after the initial setup.
Comparison of attack vectors on platforms
Business logic of attack: why break ticking
ITSM-platform is not a headlapse, but a registry of the entire IT infrastructure and a configuration management point. For the attacker, value is determined by three things.
CMDB as an infrastructure map. The ticketing system includes lists of servers, network segments, applications and their owners - this is Data from Information Repositories (T1213, Collection) One SSRF with access to the internal API - and the attacker receives a card of all infrared without a single scan. Why make noise with nmap, when everything is already neatly arranged on the shelves?
Credential harvesting from typets. Employees apply configes with passwords, screenshots, links to internal resources - Credentials In Files (T1552.001, Credential Access) ServiceNow Knowledge Base, Confluence next to Jira is a repository of secrets to which it is enough to get reading.
Lateral movement through integration. Integrations with GitHub, Slack, PagerDuty, Jenkins use OAuth tokens and webhook secrets - Trusted Relationship (T1199, Initial Access) Compromise ITSM gives access to all connected systems through trusted connections - without having to break each separately.
From the point of view of kill chain, attacks through the ticking system work on the phase of initial access - Exploit Public-Facting Application (T1190) - when Jira or Service Now stick out for contractors - and when post-exploitation on the internal network, when the attacker searches for a way to domain admin through trusted connections of the ITSM platform.
SSRF attacks via Mobile Plugin for Jira (CVE-2022-26135)
CVE-2022-26135 - server-side request forgery in Mobile Plugin for the Jira Data Center and Server, discovered by the guys from Assetnote. The vulnerability also affects the Jira Service Management Server/Data Center, as Mobile Plugin is included. CVSS 6.5 (MEDIUM), CVSS vector:3.1/AV:N/AC:L/L:L/UI:N/C/I:N/I:N/A:N. Classification CWE-918 (Server-Side Request Forgey). CISA SSVC solution - Track, not confirmed by mass operation, CVE is absent from CISA KEV.
Affected by Atlassian Jira Server and Data Center versions 8.0.0 ≤ v < 8.13.22, 8.14.0 ≤ v < 8.20.10, 8.21.0 ≤ v < 8.2.24., as well as Jira Service Management Server and Data Center versions 4.0.0 ≤ v < 4.13.22, 4.14.0 ≤ v < 4.12.0 ≤ v < 4.2.2.0. According to CISA SSVC - technical impact partial, automation is not confirmed, but the EPSS 0.84 indicates a high model probability of operation (EPSS - probability assessment based on signs of vulnerability and public activity, and not an indicator of confirmed attacks in-the-wild).
Vulnerability Mechanics and Operation Chain
The root of the problem is class BatchServiceImpl.java in Mobile Plugin. Endpoint /rest/ receives a JSON array of requests and executes them on the server side. According to Assetnote, the URL is formed through concatenation URI.create(this.jiraBaseUrls.baseUrl() + path). The attacker transmits to location Meaning @targethost.com, and it turns out the URL https://[email protected]. HTTP client OkHttpClicent interprets part to @ how userinfo and sends a request for targethost.com. Elegant and simple.
SSRF (assetnote) features: sending up to 5 queries simultaneously via batch API, arbitrary HTTP method, arbitrary headers, and query body. Restrictions: The protocol is not directly controlled (needed HTTP-edit to change HTTPS to HTTP), the Host title may not be substituted.
Critical nuance - SSRF requires authentication. But the Jira Service Desk (often installed next to Jira Core) supports self-registration through /servicedesk/customer/user/signup. Service Desk account gives access to the REST API Jira Core - Valid Accounts (T1078, Initial Access) According to the documents - the service Desk account is limited. In practice, it is enough for SSRF.
Full chain of attack:
1. ReconRecon: Recore Jira on the perimeter, determination of the version through /rest/api/2/serverInfo
2. Self-registration : Creating an account via Service Desk signup (T1078)
3. SSRF : request for batch endpoint with payload @internal-host
4. Pivot : reading cloud metadata (169.254.169.254), access to the internal API
5. Post-exploitation : Requiring tokens, CMDB data, piston to internal services
Assetnote has published a technical review with a description of the PoC in their blog (assetnote.io/resources/research) The existence of a separate public PoC repository requires verification before use.
When the technique is NOT working:
• Jira Cloud - another architecture, Mobile Plugin is not installed as an on-prem component
• Pattated versions (8.13.22+, 8.20.10+, 8.2.24.+)
• Self-registration is disabled and no valid account details
• Network segmentation: SSRF is useless if Jira is isolated from sensitive services
• WAF with rules on SSRF-patterns in JSON body (happened, but happens)
STI vulnerability ServiceNow and Freshservice: templaters as an input point
ITSM platforms use templaters to render email notifications, self-service portals and dashboards. Server-side template injection in helpdesk-cheblobnizers - a vector that Russian-speaking sources do not cover at all, although in practice it is regularly found.
Freshservice works with Liquid-like templates for customization of email notifications and portal. On one of the projects, I found that the "Theme of the Appeal" field was rendered through a template builder without shielding: payload {{7*7}} in the topic of the ticket returned 49 in the email notification to the operator - the classic SSTI marker. Liquid has a sandbox that limits a set of available filters and tags, so that full RCE through pure Liquid is unlikely without additional primitives. But reading the configuration and environment variables is a realistic scenario.
ServiceNow uses Jelly (Apache Jelly) for UI server rendering and Glide scripts in JavaScript (T1059.007, Execution) for business logic. Caste-based workflow scripts and Scripted REST API are the main surface for code injection. On several projects, I used SSRF via custom workingflow scripts ServiceNow, where the user input from the ticket got into the server script without sanitation. Injection in Glide-context can give the execution of an arbitrary server code, but for this purpose the input must get into GlideRecord or GlideAjax request.
Restrictions of STI in ITSM:
• The attack requires that the user input is rendered in a template context - depends on the customization of a particular instance
• SaaS versions (cloud) are usually more strictly isolated than on-premise
• ServiceNow ACL-policies restrict access to the emailload delivery API
• SSTI testing generates email notifications - without the consent of the customer it is easy to burn (and spoil the relationship)
Abuse webhook integrations: off address via helpdesk
[Applicable: internal pentest, post-exploitation after receiving admin-access to ITSM]
The operation of ITSM integrations is perhaps the most underappreciated vector. Every integration is trust boundary that no one simulates in a threat model. I'm bumping at this over and over again.
Jira SM -> GitHub/Bitbucket. Webhook notifications when creating tickets transmit data in the repository. Reverse integration uses OAuth tokens with read and write rights. Compromise of Jira - access to the source code. According to the Exalate Integration Review, the typical Ligale of the Jira-ServiceNow synchronizes the ticklet fields, comments, attachments and statuses is a gidanrection overall. Each of these channels is a potential vector for data injection or interception.
ServiceNow -> Slack/Teams. Integrations for notifications use bot-tokens with broad rights. Through these tokens, you can read channels, send messages on behalf of the bot, collect data from chats - Web Protocols (T1071.001, Command and Control)
Freshservice -> PagerDuty/OpsGenie. Webhook secrets are stored in the integration configuration. When accessing the admin panels, these secrets are extracted and used to manipulate the incident process.
In red team-projects OAuth-tokens of integrations are often stored in the open form in the ITSM platform configuration. Having received administrative access - for example, through privilege escalation - for example, CVE-2026-9614 (Improper Access Control in Ivanti Neurons for ITSM, CVSS 8.8 HIGH, CWE-284; there are no technical details and there are no public PoCs, SSVC Exploitation=none, EPSS 0.004 - is given exclusively as an illustration of the privilege escalation class, not a working vector) - the attacker potentially extracts tokens of all connected systems (if there is a working operator).
Webehook work as a bidirectional vector. If the attacker controls the target URL - through SSRF or administrative access - three paths open: intercepting data from the ticket by redirecting webhook to a controlled server, an injection for an automation trigger and creating false tickets, harvesteddentialing from webhook data that contain internal identifiers and sometimes tokens.
Adjustments to the environment
• OS : any with support for Burp Suite Pro (Windows/macOS/(GNU/Linux))
• RAM: at least 8 GB (Burp Suite + browser + nuclei), recommended 16 GB when running parallel with several instances
• Tools : Burp Suite Pro (2024.x+), nuclei (ProjectDiscovery, actively supported, weekly updates), curl
• Network : Access to Target ITSM-Instand - External or via VPN for Internal Pentest
• Additionally : custom nuclei templates for CVE specific ITSM-platforms
Step 1: Definition of platform and version
For Jira - endpoint /rest/api/2/serverInfo returns the version, type of deck and build number. No authentication: the title X-ASEN In response, the patterns in HTML login pages. ServiceNow - endpoint stats.do (if not closed by ACL), cookie pattern glide_session_store, version in HTML comments. Freshservice is defined by HTTP response headers, URL patterns (/support/tickets/), meta tags.
Step 2: Test self-registration
For Jira: POST on /servicedesk/customer/user/signup. The presence of endpoint does not guarantee the included registration - you need to send a real request (according to Assetnote data). For ServiceNow: check /self_registration.do.
Step 3: Scanning known CVE
For STI: create a ticket with payload {{7*7}} in the fields "theme", "description", custom fields. Check rendering in email notifications and on the portal. To agree with the customer in advance - testing generates real notifications.
Step 4: The Integration Audit
If there is administrative access (or after the privilege escalation): extract OAuth-tokens, webhook-URL and API keys from the integration section. Check the rights of each token - often they are redundant. In practice, I have never seen anyone reviving the rights of OAuth tokens after the initial setup.
Comparison of attack vectors on platforms
