WP Manifestindependent plugin directory
manifest / integrations / wp-github-release-listener

Github release listener WP RegistryHigh-severity findings · 2 findingsOpen the reportD+

Wordpress plugin to listen to a GitHub webhook and create a new post every time a release is made.

by Piiu Pilt, Silktide · github.com/silktide/wp-github-release-listener

★ 3stars
v1.1latest · 9 years ago

Install

Download source zip No release zip yet

This is the repository archive. It installs, but the folder name will carry the branch suffix and updates will not flow.

Install straight from GitHub with WP-CLI:

wp plugin install https://github.com/silktide/wp-github-release-listener/archive/refs/heads/master.zip
No built-in updater. New versions won't appear under Dashboard → Updates. Install new releases yourself, or let Git Updater track the repository.
Readme github.com/silktide/wp-github-release-listener ↗

GitHub release listener for WordPress

Wordpress plugin to listen to a GitHub webhook and create a new post every time a release is made.

Installation

  • Upload the zip via WP admin panel (Plugins > Add New > Upload Plugin) or extract it to your plugins folder

Setup

  1. Open plugin settings (Settings > GitHub release listener)
  2. Go to your project settings on GitHub
  3. Select Webhooks -> Add webhook
  4. Copy payload URL from the plugin settings to GitHub
  5. Select "application/json" as content type
  6. Create a passcode (a random string) and copy it to "Secret" field on both plugin settings and GitHub
  7. Choose "Let me select individual events" as triggers
  8. Tick "Release" and untick everything else
  9. Save your plugin settings
  10. Click "Add webhook" on GitHub

GitHub sends a ping to your payload URL on webhook activation. It can be found under Recent Deliveries and details will open upon clicking on the most recent one. In case the activation was successful the Response tab should read 200 and response body should be {"success":true,"release_published":false}.

Please note that nothing will be published on your site before an actual release is made on GitHub.

Usage

A new post (or a custom post type is that option is selected) will be created every time a release is made on GitHub. You can display the release post with your other posts or use the shortcode to generate changelogs or links to the latest release.

Example usage: Create a page named "Changelog" containing shortcode [wgrl-changelog]

Shortcode

[wgrl-changelog]

Displays full changelog. Shows release name and body by default. Options:

  • title - Show release title Default: true
  • date - Show release date in the post title. Default: false
  • downloads - Append download links (zip and tar) to every post. Default: false
  • limit - Number (int) of releases to show. Default: false

[wgrl-latest]

Displays data of seleted type from the latest release. Useful for generating download links/buttons. Options:

  • type - What to show. Available values:
  • 'title' - return latest release title
  • 'tag' - return latest release tag
  • 'zip-url' - return URL to download release as a zip file
  • 'tar-url' - return URL to download release as a tar file
  • 'zip-link' - return title, which is a link to download release as a zip file (default)
  • 'tar-link' - return title, which is a link to download release as a tar file
  • classes - Add classes to links. Restricted to types zip-link and tar-link only.

Releases

2 releases.

Tag
Published
v1.1 latest
Apr 10, 2017 9 years ago
v1.0
Feb 20, 2017 9 years ago

These releases are tags only. The author does not attach a packaged zip, so there are no download counts to report.

D+ grade

Security

Github release listener 1.1 · audited by WP Registry

High-severity findings.

1 high 1 medium
Audited release
1.1
Findings
2
Worst severity
high
Content hash
22fad7f3e6b42d742e0a04df…

Findings

  • high Webhook signature uses empty default secret; unauthenticated post publishing and stored XSS via unescaped download URLs

    missing_auth

    wgrl_new_release_handler is registered on wp_ajax_nopriv_wgrl_release_post and authenticates only by comparing X-Hub-Signature to hash_hmac('sha1', php://input, get_option('wgrl-webhook-secret')). Nothing rejects a missing/empty secret, so on any install where the secret was never saved (the default after activation) an attacker computes the HMAC with an empty key and gets wgrl_add_post() to publish arbitrary posts. The handler stores release.tarball_url / zipball_url / tag_name verbatim in post meta; the [wgrl-changelog] and [wgrl-latest] shortcodes echo those values into href attributes without esc_url/esc_attr, so a payload like 'x" onmouseover="..."' yields stored XSS for all visitors, including administrators.

    wp-github-release-listener.php:14-67

    Recommendation

    Reject requests when the secret option is empty; use hash_equals() with sha256 (X-Hub-Signature-256); sanitize stored URLs with esc_url_raw() and escape output with esc_url()/esc_attr()/esc_html().

  • medium Contributor stored XSS via unescaped [wgrl-latest] 'classes' shortcode attribute

    xss_stored

    wgrl_latest() builds ' class="' . $options['classes'] . '"' from the raw shortcode attribute and returns it in the anchor. Contributors (no unfiltered_html) can embed the shortcode with a quote-breaking classes value to inject event-handler attributes that execute when the post is previewed by an editor/admin or published. Requires at least one release post to exist.

    wp-github-release-listener.php:113-137

    Recommendation

    Escape with esc_attr() (or sanitize_html_class per class) and esc_url() for hrefs.

WP Registry hashes the installable build and reports on that exact bytes-for-bytes copy. Embargoed findings are withheld until they are disclosed, so a clean verdict means nothing public is outstanding. WP Manifest does not audit code itself.

Full report on WP Registry →