Could you please confirm whether CVE-2026-39712 is fixed in tagDiv Composer 5.4.5, and ask WPScan, Patchstack and Wordfence to update the patched version metadata? Jetpack Scan is still flagging td-composer 5.4.5 because the vulnerability databases list affected versions as <= 5.4.3 but also show “no known fix”.

Hi,

Quick update after upgrading Newspaper to v12.7.5.

The issue still reproduces with the Accessibility module enabled (Template Settings → Accessibility (Keyboard + Skip link + Search dialog)), but the behaviour has slightly changed due to the update.

Before 12.7.5, the focus/ARIA conflict typically involved #maincontent. After 12.7.5 (changelog mentions “Accessibility, improved main content wrapper selector”), the browser warning now consistently shows the ancestor being hidden/inert is #td-outer-wrap:

“Blocked aria-hidden on an element because its descendant retained focus…”
Focused element: #td-header-search-button / #td-header-search-button-mob
Ancestor with aria-hidden/inert: div#td-outer-wrap

So the underlying problem remains the same (ARIA hidden/inert applied to a container that still contains the focused search trigger/input), but the update appears to have changed which wrapper is targeted by the Accessibility logic.

We currently mitigate this with a temporary hotfix on our side that prevents aria-hidden/inert from being applied to the wrapper being targeted. After the update, that mitigation had to be adjusted from #maincontent to also cover #td-outer-wrap, which matches the new runtime behaviour.

In short: 12.7.5 changed the target wrapper, but the focus/aria-hidden timing conflict is still present.
Thank you.
Regards.

Hi Calin,

Thanks for the suggestions — we tested exactly as requested (logged in, no cache, and only tagDiv/theme plugins active) and the issue still reproduces reliably on our side on both desktop and mobile.

From comparing the DOM between an installation where the search works and our installations where it fails, the key difference is where the theme’s Accessibility module ends up placing/targeting #maincontent. The module (via tdAccessibility.js) assigns/normalises the #maincontent container based on what it detects in the page structure (e.g., presence/absence of a proper <main> element and the surrounding wrappers). On our affected sites, #maincontent resolves to a wrapper that also contains the header/search trigger, so when the search is opened the script attempts to apply aria-hidden/inert to #maincontent while focus is still on the search trigger. Chromium then blocks aria-hidden in that state (“descendant retained focus”), and the page ends up in an inconsistent/blocked interaction state.

This would also explain why the same setting appears to work on a generic installation: if #maincontent resolves to the actual content area (excluding the header), the search trigger is not a descendant of #maincontent, so the focus/aria-hidden conflict never happens.

Thank you.

Hello, Jetpack has identified the same vulnerability and indicates that it is high risk.

I have the theme updated and I have already uninstalled and reinstalled the plugin (via the theme, which supposedly retrieves the latest version from your servers), but the problem persists!

However, the information available at: https://wpscan.com/vulnerability/0ecaeb97-4f67-4e79-bea8-9c9a6ab7add3/

Says it’s resolved, but how can we access the latest (fixed) version of the plugin?

They can help us.

Thank you.

In order to improve accessibility to WCAG 2.0 AA compliance, it is important to add a Skip to Content link (it will allow you to go directly to the post content, ‘skipping’ the menu for example), for this there must be an element with an ID to which this link can be pointed.
In the case of personalized pages this is easy.
But in the case of predefined post templates (e.g.: style1, style2…) how can we add an ID to the DIV with the ‘.td-container-wrap’ class, considering that this class is indicative of the main content. Is there a snippet we can add? Or will you add this ID in the future to improve the theme’s accessibility?

Thanks.

Hello virajbpd, this is a known problem with Cloudflare, the best thing is to create a Configuration Rule in CloudFlare to disable Rocket Loader whenever wpeditor.php is used and in the entire backoffice (*/wp-admin/*), in the latter case would be a Page Rule (bypass cache level, disable apps, disable performance).

Best wishes for success.

Hello Anamaria, it didn’t work!
I cleared the browser, server and cloudflare cache.
Cpt courses continues to appear.
Thanks.

Hello Anamaria, I have the theme installed on 3 sites and one staging, on none of them I installed the plugin and this ctp courses appears, right after the update!
On one of the sites, I installed the plugin, activated it and then deleted it and it didn’t disappear!
Another one I just updated to 12.5 and the same thing happened. The ctp courses appears.

Thanks.

Hello Anamaria, I don’t have this plugin installed!
Thanks.

Hi Calin, I’m getting confused.
Sometimes it appears correctly, sometimes it doesn’t. I still thought it was from Cloudflare or Jetpack, but even deactivating both there are some pages that appear with a cloud template, but after a page refresh, they already appear with the default layout.

In categories we don’t have any globally assigned template:
https://recordeuropa.com/wp-content/uploads/2023/07/no-template1.png

In the video subcategories, all have defined a “Category Cloud Library Template”, none have the default layout. With the exception of two (which do not appear in the examples I indicated), no cloud template has a mobile version created, it only uses the responsive one:
https://recordeuropa.com/wp-content/uploads/2023/07/cloud_template1.png

All video category pages should appear on mobile, like this:
https://recordeuropa.com/wp-content/uploads/2023/07/cloud_template2.png

But, for some reason I don’t understand, they appear (sometimes) like this:
https://recordeuropa.com/wp-content/uploads/2023/07/no-template2.png

https://recordeuropa.com/videos/camera-record

The following page already has a mobile version created and this situation does not occur:
https://recordeuropa.com/videos/fala-portugal

I don’t know if you can understand what’s going on, or help me, but thanks anyway for your attention.

Best regards.

WP 6.2.2
PHP 8.2.8
Newspaper 12.4
WP Language pt_PT
Jetpack (mandatory in WP.com) 12.3

Hi Calin, this is weird. It was ok just now and it isn’t anymore. On other pages the error happens on mobile:

https://recordeuropa.com/videos/50-por-1
https://recordeuropa.com/videos/camera-record
https://recordeuropa.com/videos/quatro-patas
https://recordeuropa.com/videos/quando-me-apaixono
https://recordeuropa.com/videos/a-grande-conquista

I thought it was some caching or compression plugin, but I’ve disabled them and the problem remains.

Can you check again please?
Thanks.

Thank you so much.

FYI, CoBlocks 3.0.2 solve the problem.

Just to let you know that new version of CoBlocks 3.0.1 creates a critical error in the Newspaper Editor. I already communicated to WordPress.com, because in our case they manage this plugin.

Hello, we had already tested this option, I forgot to inform you.
Anyway, we tested it again on several sites and nothing changes.

Brilliant, it’s resolved (desktop/mobile).
You are fantastic!

I disabled, deleted and reinstalled composer and it works.

Thanks.

Hi, at WordPress.com we don’t really have control over the object cache. Because we only have Jetpack, which I have already disabled the accelerations. I also forced a rebuild of the database which forces an object cache cleanup. The problem remains.

I don’t think that could be the reason either, since in WP 5.9 everything was ok. It may even be from WP 6.0 itself, but this is already beyond me.
We continue to wait and available for whatever you need most, to resolve this situation.
Thanks.

Hello, it is not resolved!
I already replied to your email yesterday and still haven’t received a response.

Your update 11.5.1 did not resolve the issue and it is not a cache issue.
As I said before, after saving the menu, go to the homepage and everything will appear fine, but if we refresh the homepage, the menus appear wrong again.

Please check.
Thanks.

Hello Anamaria, I replied by email contact@tagdiv.com.

Hello, we’ve already tried removing these categories, but it doesn’t change anything (see image:https://recordeuropa.com/wp-content/uploads/2022/05/menu-teste.png).
Meanwhile, we have put them back.

In fact they’ve been like this for months and with WordPress 5.9 we’ve never had any problems.
On the other hand, on the website that we have under development, these categories do not exist as shown in the images that we have already mentioned:
https://recordeuropa.com/wp-content/uploads/2022/05/mega-menu-with-sub-categories.jpg

And the problem remains.

Once again I point out that we have already tried to disable other plugins that may conflict and nothing works.

If the menu is updated, the first time you enter the front end the menu appears correct, but a simple refresh of the page (even without cache) the problem appears again.

You have access to our staging site, please use it if you think it can help you.

Thanks.

Just one more information, after the update, in the Appearance > Menu options, the option ‘Make this category mega menu’ already appears. However, if we save the menu and check the font end, the first time the mega menu appears with the correct subcategories. But but with a simple refresh, everything goes wrong again! very strange. You can check on our staging if you want.
Thanks.

• This reply was modified 4 years by RECORD EUROPA.

We’ve already updated (11.5.1) our site on staging and it doesn’t work.
You can check if you want – you have access.

Unfortunately, it didn’t work!
We tried several times on both sites.

Thanks,

• This reply was modified 4 years by RECORD EUROPA.

As I reported at WordPress.com we cannot go back on the wordpress version.
On this platform some areas are controlled by hosting [Wordpress (6.0), PHP (8.1.6), Jetpack, server, database, Yoast among others], which is great for us, but these updates are automatic and irreversible.
We have already sent you the access to our staging.
So, we’ll wait for the update.

Thank you for your attention and patience. Your theme, and your team, are fantastic – which I don’t think you are told here often enough.

Unfortunately at WordPress.com we cannot go back on the wordpress version.
We’ve also tried going back to the previous version of the theme (11.4.3), but that doesn’t work either.