Something similar happened in the past with %attr being used and not being reset.
This was fixed in rpm-4.13.0.1-8.fc27 with the following patch:
0015-reset-buildid-file-attrs.patch
Which was https://bugzilla.redhat.com/show_bug.cgi?id=1432372
Upstream patch: http://lists.rpm.org/pipermail/rpm-maint/2017-March/005252.html

Apparently something similar is needed for %config. But I don't know what exactly.

Yeah its closely related to bug 1432372, this seems to fix it but didn't commit as I didn't look too closely and only cursory testing:

diff --git a/build/files.c b/build/files.c
index f58569e..77cbd9d 100644
--- a/build/files.c
+++ b/build/files.c
@@ -1843,6 +1843,8 @@ static int generateBuildIDs(FileList fl)
               Uses parseForAttr to reset ar, arFlags, and specdFlags.
               Note that parseForAttr pokes at the attrstr, so we cannot
               just pass a static string. */
+           fl->cur.attrFlags = 0;
+           fl->def.attrFlags = 0;
            fl->def.verifyFlags = RPMVERIFY_ALL;
            fl->cur.verifyFlags = RPMVERIFY_ALL;
            fl->def.specdFlags |= SPECD_VERIFY;

Longer term, it might actually be easier to have generateBuildIDs() generate %files manifests which are fed into the spec parsing routines instead of doing this stuff manually. Because .. as you've witnessed, the internals are not very well suited to this, to put it mildly :)

If whatever "inherited" values these variables have should be cleared and replaced with the default values, why does it say "specdFlags |= SPECD_VERIFY" and not "specdFlags = SPECD_VERIFY"?

(In reply to Panu Matilainen from comment #2)
> Yeah its closely related to bug 1432372, this seems to fix it but didn't
> commit as I didn't look too closely and only cursory testing:
> 
> diff --git a/build/files.c b/build/files.c
> index f58569e..77cbd9d 100644
> --- a/build/files.c
> +++ b/build/files.c
> @@ -1843,6 +1843,8 @@ static int generateBuildIDs(FileList fl)
>                Uses parseForAttr to reset ar, arFlags, and specdFlags.
>                Note that parseForAttr pokes at the attrstr, so we cannot
>                just pass a static string. */
> +           fl->cur.attrFlags = 0;
> +           fl->def.attrFlags = 0;
>             fl->def.verifyFlags = RPMVERIFY_ALL;
>             fl->cur.verifyFlags = RPMVERIFY_ALL;
>             fl->def.specdFlags |= SPECD_VERIFY;

Yes, that fixes it. I added a testcase and submitted upstream:
http://lists.rpm.org/pipermail/rpm-maint/2017-May/005598.html

> Longer term, it might actually be easier to have generateBuildIDs() generate
> %files manifests which are fed into the spec parsing routines instead of
> doing this stuff manually. Because .. as you've witnessed, the internals are
> not very well suited to this, to put it mildly :)

Yeah, in hindsight. But I think I avoided that because I was afraid of quoting and glob escaping issues. Maybe there are none?

(In reply to Mattias Ellert from comment #3)
> If whatever "inherited" values these variables have should be cleared and
> replaced with the default values, why does it say "specdFlags |=
> SPECD_VERIFY" and not "specdFlags = SPECD_VERIFY"?

I must admit I don't actually know. It looks like specdFlags are always ORed. And you always want all verification done on the files. parseForAttr ORs in all the other flags. So probably the default is that all are set. But I don't really understand myself. Panu?

This is fixed in rpm-4.13.0.1-23.fc27 but for some reason I seem unable to add the fixed in version field or change the status.