OWASP® Smart Contract Top 10 (2026) Now Live. A Baseline for Smart Contract Security.Industry Security Report 2026 Now Live. AI-led Pentesting Benchmark.Learn more about our findings.Explore →Read Report →
CVE-2026-10753: A Broken Access Control Flaw CredShields Found in Google’s Site Kit
An editor level user with dashboard sharing access could change a sitewide setting through a REST API endpoint that should have been admin only. Here is the full technical breakdown of the flaw and the one line authorization mistake behind it.
Site Kit by Google protected its email reporting settings page in the admin UI, but the matching REST API write endpoint checked for a view level capability instead of an administrator level one. Any authenticated user who had been granted dashboard sharing access (for example, an Editor) could send a direct API request to flip a site wide setting they were never meant to touch. The fix in 1.176.0 swaps the permission callback to require administrator capabilities. Update the plugin to 1.176.0 or later.
Site Kit by Google is one of the most widely deployed plugins in the WordPress ecosystem, with more than 5 million active installations. It is the official Google plugin that pulls Search Console, Analytics, PageSpeed Insights, and AdSense data into the WordPress dashboard.
Because it ships from Google and sits on millions of sites, its security posture has an outsized blast radius, a single authorization slip is replicated across a very large surface.
One feature is central to this vulnerability is dashboard sharing. Site Kit lets an administrator share specific dashboards with other roles, so an Editor can view Search Console or Analytics metrics without being handed full administrator access.
That feature is genuinely useful, and it is exactly the kind of delegated access feature that quietly widens the authorization surface of an application. Every capability you grant for viewing has to be cleanly separated from the capabilities that allow writing. CVE-2026-10753 is what happens when that line blurs by a single function call.
The vulnerability
Site Kit exposes a REST endpoint for its email reporting feature, core/site/data/email-reporting. The read path (GET) is meant to be visible to users who can see the dashboard. The write path (POST, PUT, PATCH) toggles a sitewide enabled flag and should only ever be reachable by an administrator.
The problem is that the write endpoint’s permission callback used the wrong capability check.
Instead of requiring administrator level capability, it accepted a view level capability, the same one a dashboard sharing Editor already holds. The administrative Settings page in the UI correctly returned HTTP 403 for those users, which created a false sense of safety.
The API, however, never enforced the same rule. An Editor with shared dashboard access could bypass the UI entirely and write the setting with a direct request, because authorization was enforced in the interface but not at the API boundary.
The pattern in one sentence: the UI hid the control, but the API did not enforce it. UI layer gating is presentation. Authorization has to live on the endpoint.
Root cause: $can_access where it needed $can_manage
Site Kit models permissions with named capabilities. Two of them matter here:
VIEW_SPLASH and VIEW_DASHBOARD are view level. Dashboard sharing grants these to non admin roles like Editors. The plugin bundles them as a helper that resolves to “can this user see Site Kit,” internally referenced as $can_access.
MANAGE_OPTIONS maps to WordPress’s manage_options capability, the marker of an administrator. It is bundled as $can_manage.
The write callback for core/site/data/email-reporting was wired to $can_access (view-level) rather than $can_manage (admin-level). Conceptually, the registration looked like this:
// REST_Email_Reporting_Controller::get_rest_routes() (condensed from 1.176.0)
$can_access = function () {
return current_user_can( Permissions::VIEW_SPLASH )
|| current_user_can( Permissions::VIEW_DASHBOARD );
};
$can_manage = function () {
return current_user_can( Permissions::MANAGE_OPTIONS );
};
new REST_Route(
'core/site/data/email-reporting',
array(
array( // GET: reading is fine for shared dashboards
'methods' => WP_REST_Server::READABLE,
'permission_callback' => $can_access,
),
array( // POST/PUT/PATCH: writes a site-wide setting
'methods' => WP_REST_Server::EDITABLE,
'permission_callback' => $can_access, // BEFORE: bug, view-level grant accepted
// 'permission_callback' => $can_manage, // AFTER 1.176.0: admins only
),
)
);
What makes this a clean, textbook finding is the inconsistency.
The sibling write endpoints in the very same controller already required $can_manage, including the eligible subscribers, errors, and invite user routes. Other site wide settings controllers in the plugin, such as consent mode and conversion tracking, also consistently require MANAGE_OPTIONS for writes. This single endpoint was the outlier.
It is a reminder that authorization bugs rarely come from a developer who does not understand access control. They come from one endpoint that drifted out of step with the convention everywhere around it.
Reading the CVSS and why the class still matters
The vector is CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N, a base score of 2.7 (Low). Broken down:
AV:N (Network) and AC:L (Low complexity): the endpoint is reachable remotely with a straightforward request.
PR:H (High privileges required): the attacker is not anonymous. They must already be an authenticated user who has been granted dashboard sharing access, a partly trusted role. This is the single biggest reason the score stays low.
UI:N (No user interaction): no admin has to click anything.
S:U, C:N, I:L, A:N: scope is unchanged, there is no data disclosure or downtime, and the only impact is a low integrity change: flipping one sitewide setting.
This is a low severity bug in isolation. The class is broken access control, which has sat at the top of the OWASP Top 10 (A01:2021) precisely because the same root cause, an endpoint that trusts a capability it should not, scales from “harmless setting toggle” to “privilege escalation” depending only on what the endpoint happens to write. The discipline that catches the low severity version is the same discipline that prevents the critical one.
Exploitation, in concept
The attack requires no exotic tooling. A user who already holds a shared dashboard role authenticates as normal, then issues a write request directly to core/site/data/email-reporting rather than going through the Settings page that would have blocked them. Because the endpoint only checked for view access, the request succeeded and the sitewide flag changed.
The fix
The patch, merged upstream and shipped in Site Kit 1.176.0, changes the write endpoint’s permission callback from the view level $can_access to the admin level $can_manage.
After the fix:
An administrator can still toggle email reporting from the Settings UI
A shared dashboard Editor now receives HTTP 403 when attempting to POST to the endpoint
That same Editor can still read (GET) the setting, preserving the legitimate dashboard sharing behavior
The other email reporting endpoints are unaffected, since they already enforced administrator capability
The change brings the outlier endpoint back in line with every other sitewide write route in the plugin.
What site owners should do
Update Site Kit to 1.176.0 or later
Review who holds dashboard sharing access
Audit your plugin update hygiene generally
Lessons for developers building on the WordPress REST API
This finding is small, which is what makes it instructive. The mistakes that produce it are extremely common across WordPress plugins and custom REST integrations.
1. Authorize at the endpoint, never at the UI
If a Settings page returns 403 but the underlying endpoint does not, you have not implemented access control. You have implemented a visual nicety. The permission_callback on every register_rest_route call is the actual gate, and it must reflect the real privilege required to perform the action, not the privilege required to see the screen.
2. Separate read capability from write capability, explicitly
Features like dashboard sharing exist to let lower privileged users read. The moment a write endpoint reuses a read capability, the read grant silently becomes a write grant. Read and write should resolve to different capability checks by default, and any exception should be a deliberate, reviewed decision.
3. Treat endpoint-to-endpoint consistency as a security property
The bug here was a single route that diverged from a convention its siblings already followed. A quick consistency sweep, “do all sitewide write routes in this controller use the same admin level check,” would have surfaced it immediately. Convention drift is one of the most reliable sources of access control bugs, and it is exactly the kind of thing a manual review catches that a generic scanner does not.
4. Low severity is not low priority for high install software
A 2.7 on one site is noise. A 2.7 replicated across 5 million sites, in a class that historically escalates, is worth a same day patch. Google treated it that way, and the fix was clean.
Frequently asked questions
What is CVE-2026-10753?
It is a broken access control vulnerability (CWE-863, Incorrect Authorization) in Google’s Site Kit WordPress plugin below version 1.176.0. A REST API write endpoint used a view level permission check instead of an administrator level one, letting Editor level users with dashboard sharing access modify a site wide email reporting setting. It was disclosed by CredShields and fixed in 1.176.0.
Which versions are affected?
All versions of Site Kit by Google below 1.176.0. Update to 1.176.0 or later.
How severe is it?
CVSS 3.1 base score 2.7 (Low). The low rating reflects that exploitation requires an already authenticated user with dashboard sharing access, and that the only impact is toggling one non critical site wide setting, with no confidentiality or availability impact.
How do I fix it?
Update the Site Kit by Google plugin to 1.176.0 or later.
Who discovered it?
Shashank of CredShields discovered and responsibly disclosed the issue, with the fix merged upstream into the Site Kit repository.
Broken access control rarely shows up as a dramatic bug. It shows up as one endpoint that trusts the wrong capability while everything around it does the right thing. Automated scanners read code patterns. Catching an authorization drift like CVE-2026-10753 takes a tester who maps every route to the privilege it actually requires. That is what our application security team does.
