CVE-2026-1228: 
WordPress vulnerability analysis and mitigation

CVE-2026-1228 is an Insecure Direct Object Reference (IDOR) vulnerability in the Timeline Block – Beautiful Timeline Builder for WordPress plugin, developed by bPlugins. It affects all versions up to and including 1.3.3, allowing authenticated attackers with Author-level access or above to disclose private timeline content by manipulating the id attribute of the timeline_block shortcode. The vulnerability was published on February 6, 2026, and assigned by Wordfence. It carries a CVSS v3.1 base score of 4.3 (Medium) (Wordfence, Red Hat CVE).

The root cause is classified as CWE-639: Authorization Bypass Through User-Controlled Key. The vulnerable tlgb_shortcode() function fails to validate whether the requesting user is authorized to access the timeline post identified by the id parameter passed to the timeline_block shortcode. An authenticated attacker can supply arbitrary post IDs in the shortcode's id attribute to retrieve content from private timeline posts that they should not have access to. No complex exploitation technique is required — the attack is network-based, low complexity, and requires no user interaction (Wordfence, ENISA EUVD).

Successful exploitation results in unauthorized disclosure of private timeline content stored within the WordPress site, impacting confidentiality. There is no impact on integrity or availability. The scope is limited to the affected WordPress installation; lateral movement or privilege escalation beyond content disclosure is not directly enabled by this vulnerability alone (Wordfence).

No public proof-of-concept exploit code or evidence of in-the-wild exploitation has been reported as of the available data. The EPSS score is approximately 0.025%, indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires at minimum Author-level authentication on the target WordPress site, which significantly limits the attacker pool (Wordfence, Red Hat CVE).

1. Reconnaissance: Identify a WordPress site running the Timeline Block plugin at version 1.3.3 or earlier. This can be done by inspecting plugin metadata in the site's source or using tools like WPScan.
2. Obtain Author-level access: Log in to the WordPress site with an account that has at minimum Author-level privileges (e.g., via legitimate credentials or a compromised account).
3. Identify target post IDs: Enumerate WordPress post IDs for private timeline posts by iterating through numeric IDs (e.g., starting from 1 upward), which are predictable in WordPress.
4. Craft malicious shortcode: Insert a [timeline_block id="<target_post_id>"] shortcode into a post or page draft, substituting <target_post_id> with the ID of a private timeline post.
5. Preview or publish the post: Render the page containing the shortcode (e.g., via post preview) to trigger the tlgb_shortcode() function, which returns the private timeline content without authorization checks.
6. Collect disclosed content: Read the rendered output to obtain the private timeline data (Wordfence).

• Logs: WordPress access logs showing authenticated POST or GET requests to pages/posts containing timeline_block shortcodes with varying numeric id values in rapid succession, potentially indicating enumeration.
• Logs: WordPress debug logs or query logs showing repeated calls to tlgb_shortcode() with different post IDs from the same user session.
• File System: No file-system artifacts are expected, as this is a data-disclosure vulnerability with no code execution component.
• Behavior: Author-level accounts accessing or previewing posts/pages that contain [timeline_block id="..."] shortcodes referencing post IDs they did not create.

Update the Timeline Block plugin to version 1.3.4 or later, which addresses the missing authorization validation in the tlgb_shortcode() function. The patch is available via the WordPress plugin repository changeset. As a temporary workaround, site administrators can restrict Author-level user permissions or disable the plugin until the update is applied. Regularly auditing user roles and limiting the number of trusted Author-level accounts reduces exposure (Wordfence, WordPress Trac).