Make WordPress Core

Opened 9 months ago

Closed 9 months ago

Last modified 4 months ago

#49499 closed defect (bug) (fixed)

Class 'getid3_handler' not found

Reported by: manjeetwp681 Owned by:
Milestone: 5.5 Priority: normal
Severity: normal Version:
Component: Media Keywords:
Focuses: Cc:


I'm getting this issue multiple time in my kibana logs, from past 5 months we are getting the same issue.


Attachments (1)

kibana-error.png (27.9 KB) - added by manjeetwp681 9 months ago.

Download all attachments as: .zip

Change History (14)

#1 @ocean90
9 months ago

  • Component changed from General to Media
  • Keywords reporter-feedback added
  • Severity changed from critical to normal

Hello @manjeetwp681, welcome to WordPress Trac!

Thanks for your report. The class is defined in https://build.trac.wordpress.org/browser/tags/5.3.2/wp-includes/ID3/getid3.php#L1859 and the file is included in wp_read_video_metadata() and wp_read_audio_metadata(). Can you check if your getid3.php looks the same as the above? Do you have plugins enabled related to media handling? Please try disabling them to see if the error remains.

#2 @siliconforks
9 months ago

I've seen this message appear in the error log too.

It appears to be coming from a hack attempt probing for various files in the WordPress installation, one of which is the module.audio.ac3.php file:

xxx.xxx.xxx.xxx - - [23/Feb/2020:12:35:33 -0800] "GET /wp-includes/ID3/module.audio.ac3.php HTTP/1.1" 500 3467 "-" "python-requests/2.22.0"

Obviously this fails with the error message above. I don't know why the attacker is probing for that particular file.

#3 @ocean90
9 months ago

#49548 was marked as a duplicate.

#4 follow-up: @carl-alberto
9 months ago

It seems this is related to a couple of files included in the wp core from the getID3 lib https://github.com/JamesHeinrich/getID3

Steps to reproduce the error:

1) Error logging/debugging is enabled in a WP site and the host allows it
2) Visit directly the location of the said files eg: https://example.com/wp-includes/ID3/module.audio-video.asf.php it will give out the error Fatal error: Uncaught Error: Class 'getid3_lib' not found in wp-includes/ID3/module.audio-video.asf.php:16 Stack trace: #0 {main} thrown in wp-includes/ID3/module.audio-video.asf.php on line 16

Affected files
These are the files affected in the WP core in this folder wp-includes/ID3/


This vulnerability is the hosting's responsibility

Most technical users know that the path disclosure is the hosting's responsibility to address this issue but let's put our shoes in a simple user that is not very technical and can only host from the cheapest possible way where there is no staging and they always work in a live site where by default debugging is on, it would affect the user-friendliness of an application as most likely they will run into:

  • the full path is exposed by default and their site will be a favorite target for SQLI attacks and automated probes before the owners know it
  • their disk space can be maxed out when the error logs piles up
  • this user will need to hire a developer to get this coordinated to the hosting to get this turned off if he is not familiar in toggling the settings from the host

Possible long term solution

Opened up an issue here in the getID3 lib https://github.com/JamesHeinrich/getID3/issues/235 and added a patch https://github.com/JamesHeinrich/getID3/pull/236 Hopefully this will be put into consideration and merged in the WP core eventually

Last edited 9 months ago by carl-alberto (previous) (diff)

#5 @ocean90
9 months ago

  • Keywords reporter-feedback removed
  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed
  • Version 5.3.2 deleted

I have contacted some hosting providers are they have confirmed seeing similar requests. All requests where using a python-requests user agent. It looks like this file is now included in a script for backdoor check requests.

As this sort of error can happen with most of the files in wp-includes I suggest to take a look at the Hardening WordPress support document, particularly the Securing wp-includes section.

#6 @Sudavar
8 months ago


the merge request of @carl-alberto (https://github.com/JamesHeinrich/getID3/pull/236) was accepted into the getID3 lib repo, perhaps it could also be included in the next version of WordPress as well?

#7 in reply to: ↑ 4 @DrLightman
7 months ago

I've seen this Fatal Error passing by my logs today too.

Being WordPress open source it's not difficult to target and load PHP files one by one in the browser after you've downloaded the zip, opened it and learnt of which files is made of.

Maybe it would make sense to put something like:

if ( ! defined( 'ABSPATH' ) ) {
    die( 'Meh' );

On top of all files that are not index.php or are not meant to be called directly?

Last edited 7 months ago by DrLightman (previous) (diff)

#8 follow-up: @jasonpiersonawana
7 months ago

Any word on this being merged into core? We're getting these errors multiple times a day. I saw @ocean90 's comment about hardening, which is blocking those scripts using mod_rewrite in the .htaccess file. However, our host(Pantheon), ignores the .htaccess file.

#9 @carl-alberto
7 months ago

@jasonpiersonawana Pantheon is Nginx based so .htaccess won't work but as a platform mitigation, you can add those paths as a protected path in the pantheon.yml file so they cannot be accessed directly. Please see this guide https://pantheon.io/docs/pantheon-yml#protected-web-paths. Thanks!

This ticket was mentioned in Slack in #core by sudavar. View the logs.

6 months ago

#11 in reply to: ↑ 8 @SergeyBiryukov
4 months ago

  • Milestone set to 5.5
  • Resolution changed from worksforme to fixed

Replying to jasonpiersonawana:

Any word on this being merged into core? We're getting these errors multiple times a day.

In [48278] / #49945 getID3() was updated to version 1.9.20, which includes the PR mentioned above.

#12 @jasonpiersonawana
4 months ago

@SergeyBiryukov, thanks for the update! Exciting!

#13 @carl-alberto
4 months ago

Thanks @SergeyBiryukov, glad to hear that this is going into core :)

Note: See TracTickets for help on using tickets.