{"id":176,"date":"2026-10-24T09:31:23","date_gmt":"2026-10-24T09:31:23","guid":{"rendered":"https:\/\/ping4support.com\/blog\/?p=176"},"modified":"2026-10-24T09:34:35","modified_gmt":"2026-10-24T09:34:35","slug":"cve-2026-109618-109619-vulnerability-on-cpanelwhm","status":"publish","type":"post","link":"https:\/\/ping4support.com\/blog\/cve-2026-109618-109619-vulnerability-on-cpanelwhm\/","title":{"rendered":"CVE-2026-109618-109619 Vulnerability\u00a0on cPanel&amp;WHM"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\"><strong>CVE-2026-109618-109619 Vulnerability<\/strong>&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Every hosting provider running cPanel &amp; WHM has quietly agreed to trust one thing: that a crafted web request can\u2019t talk its way into running code on the server. CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell, are a crack in that trust. They are two flaws in PHP itself, both rated 9.2 (critical), that let an attacker run code on a server with a crafted HTTP request, without signing in.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">On a shared cPanel server that is close to a worst-case scenario: one vulnerable site on a node can become a way into every other account on it. PHP parses multipart upload bodies before any application script runs, so a perfectly well-written WordPress or Laravel site is still in scope.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The good news is that cPanel moved fast. This post covers what the fix changes, why a single update command is not enough on cPanel, and the exact sequence we use to roll it out one server at a time.\u00a0\u00a0<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>CVE-2026-109618 and CVE-2026-109619 allow unauthenticated remote code execution through crafted multipart\/form-data POST requests.\u00a0<\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Upstream fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. On cPanel they arrive as EasyApache 4 build 25.91 (ea-php82 to ea-php85).\u00a0<\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li>cPanel also reports backported fixes for ea-php74, ea-php80 and ea-php81, which keep their old version numbers. Verify them through the package changelog, not php -v.\u00a0<\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li>cPanel has two separate PHP layers: the EasyApache packages that serve your customers\u2019 sites, and cPanel\u2019s own internal PHP. Update both.\u00a0<\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li>PHP\u2019s own release notice says there are no complete mitigations. Config tweaks only buy time.\u00a0<\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li>After updating, restart PHP-FPM and Apache so no old worker keeps running.\u00a0<\/li>\n<\/ul>\n\n\n\n<h1 class=\"wp-block-heading\"><strong>Why This One Actually Matters<\/strong>&nbsp;<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Most PHP CVEs need something extra: a vulnerable plugin, a logged-in user, an unusual setting. This one doesn\u2019t. At least one of the flaws has been linked to session.upload_progress, which is enabled by default, so stock configurations can be in scope. CISA and the FBI both publicly urged organizations to patch immediately, and some vendors have reported exploitation in the wild.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><em>On a shared server, one unpatched PHP runtime means every account on the box inherits the risk.<\/em>&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Read the primary sources directly rather than relying on secondhand summaries, including this one:&nbsp;<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/www.php.net\/archive\/2026.php\" target=\"_blank\" rel=\"noopener\">PHP release announcement<\/a>\u00a0<\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/github.com\/php\/php-src\/security\/advisories\/GHSA-w8hw-w9fx-j79w\" target=\"_blank\" rel=\"noopener\">GHSA for CVE-2026-109618<\/a>\u00a0<\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/github.com\/php\/php-src\/security\/advisories\/GHSA-6wmf-4rv5-p3rp\" target=\"_blank\" rel=\"noopener\">GHSA for CVE-2026-109619<\/a>\u00a0<\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li>cPanel\u2019s EasyApache 4 change log and release notes (WHM > Software > EasyApache 4, and cPanel\u2019s documentation site)\u00a0<\/li>\n<\/ul>\n\n\n\n<h1 class=\"wp-block-heading\"><strong>What\u2019s Actually Going Wrong&nbsp;<\/strong>&nbsp;<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Public analysis of the fix commit points to a memory-handling problem. When PHP runs out of memory while parsing a multipart upload, it used to bail out abruptly without cleaning up, leaving dangling pointers and uncleaned global state. The next request handled by that worker then starts on top of corrupted state.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Think of a restaurant kitchen where one cook walks away mid-task, leaving knives out and burners on, and the next cook carries on from there. Attackers try to steer that mess toward running their own code. The fix adds a clean unwinding path so a failed allocation tidies up after itself.&nbsp;<\/p>\n\n\n\n<h1 class=\"wp-block-heading\"><strong>Why cPanel Needs More Than One Update<\/strong>&nbsp;<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">This is the part that catches people out. A cPanel server doesn\u2019t have \u201ca PHP\u201d. It has several, and each is patched differently:&nbsp;<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><td><strong>PHP layer<\/strong>&nbsp;<\/td><td><strong>What it serves<\/strong>&nbsp;<\/td><td><strong>How it gets fixed<\/strong>&nbsp;<\/td><\/tr><tr><td>EasyApache 4 (ea-php74 to ea-php85)&nbsp;<\/td><td>Your customers\u2019 websites, via MultiPHP and PHP-FPM&nbsp;<\/td><td>EasyApache 4 build 25.91 packages. Update with dnf\/yum.&nbsp;<\/td><\/tr><tr><td>cPanel\u2019s internal PHP&nbsp;<\/td><td>cPanel, WHM and webmail interfaces&nbsp;<\/td><td>cPanel &amp; WHM update (upcp). Check cPanel\u2019s release notes for your tier.&nbsp;<\/td><\/tr><tr><td>CloudLinux alt-php (if used)&nbsp;<\/td><td>Sites using PHP Selector&nbsp;<\/td><td>CloudLinux\u2019s own alt-php packages. Check CloudLinux\u2019s incident page.&nbsp;<\/td><\/tr><tr><td>php on the command line&nbsp;<\/td><td>Only what you type in SSH&nbsp;<\/td><td>Can be a different build than the one serving pages. Don\u2019t trust it alone.&nbsp;<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\"><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">One more trap reported by admins: running \/scripts\/upcp &#8211;security updated cPanel\u2019s internal PHP but did not always pull the EasyApache packages. We always update the ea-php packages by name as well.&nbsp;<\/p>\n\n\n\n<h1 class=\"wp-block-heading\"><strong>What the Fix Does&nbsp;<\/strong>&nbsp;<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">The remediation is a package update that closes the problem at the source. The stopgaps are weaker than they look:&nbsp;<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Setting session.upload_progress.enabled=0 is listed as a mitigation for CVE-2026-109619 only. CVE-2026-109618 is a separate path this setting does not block.\u00a0<\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li>On PHP 8.5, fatal_error_backtraces=0 blocks only one confirmed path.\u00a0<\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Blocking all multipart\/form-data requests breaks every legitimate upload on every site.\u00a0<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">If you truly cannot patch today, you can set the upload-progress option in WHM &gt; MultiPHP INI Editor and restart PHP-FPM. Treat it as a bandage and schedule the real update.&nbsp;<\/p>\n\n\n\n<h1 class=\"wp-block-heading\"><strong>Rolling It Out Without Breaking Anything<\/strong>&nbsp;<\/h1>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>1. Get a baseline<\/strong>&nbsp;<\/h2>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\">Check the cPanel version and which EasyApache PHP versions are installed:&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">cat \/usr\/local\/cpanel\/version&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">ls \/opt\/cpanel\/ | grep ea-php&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Check the version of each installed PHP directly (repeat for every ea-php directory you have):&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\/opt\/cpanel\/ea-php83\/root\/usr\/bin\/php -v&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\/opt\/cpanel\/ea-php84\/root\/usr\/bin\/php -v&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\/usr\/local\/cpanel\/3rdparty\/bin\/php -v&nbsp;&nbsp;&nbsp;&nbsp; # cPanel&#8217;s internal PHP&nbsp;<\/p>\n<\/blockquote>\n\n\n\n<p class=\"wp-block-paragraph\">Then see which PHP version each domain actually uses in WHM &gt; MultiPHP Manager. A patched ea-php84 helps nobody if the busy sites are still assigned to an old branch.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Anything below 8.5.12 \/ 8.4.27 \/ 8.3.36 \/ 8.2.35 on a supported branch is exposed.&nbsp;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>2. Check whether a fix is already in the package<\/strong>&nbsp;<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Backported branches keep their old version number, so look for the CVE IDs in the package changelog instead of trusting the version string:&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">rpm -q &#8211;changelog ea-php84-php-fpm | grep -E &#8216;CVE-2026-10961[89]&#8217;&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">rpm -q &#8211;changelog ea-php81-php-fpm | grep -E &#8216;CVE-2026-10961[89]&#8217;&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">No output means that package does not carry the fix yet.&nbsp;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>3. Update EasyApache 4 packages<\/strong>&nbsp;<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Make sure nothing else is mid-update, then refresh the metadata and update every ea-php package by name:&nbsp;<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\">ps aux | grep -E &#8216;upcp|yum|dnf&#8217; | grep -v grep&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"># AlmaLinux \/ Rocky \/ CloudLinux 8+&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">dnf clean all &amp;&amp; dnf upgrade &#8216;ea-php*&#8217;&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"># CentOS 7 \/ CloudLinux 7&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">yum clean all &amp;&amp; yum update &#8216;ea-php*&#8217;&nbsp;<\/p>\n<\/blockquote>\n\n\n\n<p class=\"wp-block-paragraph\">Don\u2019t run it twice \u201cjust in case\u201d while the first run is going, and don\u2019t interrupt it. If it errors, save the full output before touching anything else.&nbsp;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>4. Update cPanel &amp; WHM itself<\/strong>&nbsp;<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">cPanel\u2019s release notes list the security update for cPanel &amp; WHM separately from EasyApache 4. Run the normal update and confirm automatic updates are on:&nbsp;<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\">\/scripts\/upcp &#8211;force&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\/usr\/local\/cpanel\/3rdparty\/bin\/php -v&nbsp;<\/p>\n<\/blockquote>\n\n\n\n<p class=\"wp-block-paragraph\">You can review the schedule in WHM &gt; Server Configuration &gt; Update Preferences.&nbsp;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>5. CloudLinux servers<\/strong>&nbsp;<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">If you run CloudLinux, the ea-php packages and the alt-php packages used by PHP Selector are separate sets. Update both and follow CloudLinux\u2019s incident page for status.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">dnf upgrade &#8216;alt-php*&#8217;&nbsp;&nbsp;&nbsp;&nbsp; # yum update &#8216;alt-php*&#8217; on CloudLinux 7&nbsp;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>6. Restart, then verify<\/strong>&nbsp;<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Long-lived PHP-FPM workers keep running old code until they\u2019re restarted. Restart PHP-FPM and Apache with cPanel\u2019s own scripts:&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\/scripts\/restartsrv_apache_php_fpm&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\/scripts\/restartsrv_httpd&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Now repeat your baseline and confirm the changelog entries, plus service health and failed units:&nbsp;<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\">echo &#8220;===== CPANEL =====&#8221; &amp;&amp; cat \/usr\/local\/cpanel\/version&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">echo &#8220;===== EA-PHP =====&#8221; &amp;&amp; ls \/opt\/cpanel\/ | grep ea-php&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">echo &#8220;===== CHANGELOG =====&#8221; &amp;&amp; for p in $(rpm -qa &#8220;ea-php*-php-fpm&#8221;); do echo $p; rpm -q &#8211;changelog $p | grep -E &#8220;CVE-2026-10961[89]&#8221;; done&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">echo &#8220;===== FPM MASTERS =====&#8221; &amp;&amp; ps -eo pid,lstart,cmd | grep &#8220;php-fpm: master&#8221; | grep -v grep&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">echo &#8220;===== FAILED UNITS =====&#8221; &amp;&amp; systemctl &#8211;failed&nbsp;<\/p>\n<\/blockquote>\n\n\n\n<p class=\"wp-block-paragraph\">The FPM master start times should be after your update. If a master process is older than the patch, it\u2019s still running old code.&nbsp;<\/p>\n\n\n\n<h1 class=\"wp-block-heading\"><strong>Questions We Got Asked Internally<\/strong>&nbsp;<\/h1>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>\u201cDoes this upgrade the OS too?\u201d<\/strong>&nbsp;<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">No. It only touches the ea-php packages and cPanel itself. Your kernel and OS release stay exactly as they were.&nbsp;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>\u201cDo we need to reboot?\u201d<\/strong>&nbsp;<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">No. Restart PHP-FPM and Apache with the cPanel scripts and verify. An unnecessary reboot on a production shared node is a risk you don\u2019t need to take.&nbsp;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>\u201cSome customers are on PHP 7.4, 8.0 or 8.1. Are they safe?\u201d<\/strong>&nbsp;<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Upstream PHP has no official fix for those branches. cPanel reports backports for ea-php74, ea-php80 and ea-php81 in EasyApache 4 25.91, but sources have disagreed on 8.1, so confirm with the changelog check above. Older branches such as ea-php73 and below have no cPanel fix, so move those customers to a supported version. Third-party extended-support options exist if a customer truly can\u2019t migrate.&nbsp;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>\u201cIs switching a domain\u2019s PHP version in MultiPHP enough?\u201d<\/strong>&nbsp;<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">No. The server\u2019s ea-php package must be patched first. Then each domain must be assigned to a patched branch.&nbsp;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>\u201cIs turning off session.upload_progress enough?\u201d<\/strong>&nbsp;<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">No. It covers part of one of the two CVEs.&nbsp;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>\u201cWe run Imunify360 or a WAF. Are we covered?\u201d<\/strong>&nbsp;<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">They add a useful layer and may block known exploit patterns, but they don\u2019t fix PHP. Patch anyway.&nbsp;<\/p>\n\n\n\n<h1 class=\"wp-block-heading\"><strong>What to Watch For<\/strong>&nbsp;<\/h1>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Large or unusual multipart POST requests in Apache domlogs (\/var\/log\/apache2\/domlogs\/).\u00a0<\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li>PHP-FPM workers crashing or respawning, usually visible in the FPM error log (typically \/opt\/cpanel\/ea-phpXX\/root\/usr\/var\/log\/php-fpm\/error.log) and as a spike in 500\/502 errors.\u00a0<\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li>New files you don\u2019t recognize in customer web roots, or new cron jobs.\u00a0<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">If you find any of those on a server that hadn\u2019t been patched, treat it as a possible compromise: patch, then investigate, not the other way around.&nbsp;<\/p>\n\n\n\n<h1 class=\"wp-block-heading\"><strong>Where This Leaves Us<\/strong>&nbsp;<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Patching PHP2Shell on cPanel isn\u2019t complicated. It\u2019s a couple of update commands, a restart, and the discipline to cover every PHP layer on every server. If you haven\u2019t checked yet, this is the first command to run today:&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">rpm -q &#8211;changelog ea-php84-php-fpm | grep -E &#8216;CVE-2026-10961[89]&#8217;&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">No match, or an old version on a supported branch, means a clear next step. Then read PHP\u2019s <a href=\"https:\/\/www.php.net\/archive\/2026.php\" target=\"_blank\" rel=\"noopener\">official advisory<\/a> and cPanel\u2019s EasyApache 4 change log in full.&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>CVE-2026-109618-109619 Vulnerability&nbsp; Every hosting provider running cPanel &amp; WHM has quietly agreed to trust one thing: that a crafted web&#8230;<\/p>\n","protected":false},"author":1,"featured_media":177,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"pagelayer_contact_templates":[],"_pagelayer_content":"","_kadence_starter_templates_imported_post":false,"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","footnotes":""},"categories":[20],"tags":[],"class_list":["post-176","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-techncal-support"],"_links":{"self":[{"href":"https:\/\/ping4support.com\/blog\/wp-json\/wp\/v2\/posts\/176","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ping4support.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ping4support.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ping4support.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/ping4support.com\/blog\/wp-json\/wp\/v2\/comments?post=176"}],"version-history":[{"count":2,"href":"https:\/\/ping4support.com\/blog\/wp-json\/wp\/v2\/posts\/176\/revisions"}],"predecessor-version":[{"id":180,"href":"https:\/\/ping4support.com\/blog\/wp-json\/wp\/v2\/posts\/176\/revisions\/180"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ping4support.com\/blog\/wp-json\/wp\/v2\/media\/177"}],"wp:attachment":[{"href":"https:\/\/ping4support.com\/blog\/wp-json\/wp\/v2\/media?parent=176"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ping4support.com\/blog\/wp-json\/wp\/v2\/categories?post=176"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ping4support.com\/blog\/wp-json\/wp\/v2\/tags?post=176"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}